Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@Discard org.glassfish.hk2.api.Factory / @Unmanaged? #693

Open
buko opened this issue Jun 18, 2022 · 0 comments
Open

@Discard org.glassfish.hk2.api.Factory / @Unmanaged? #693

buko opened this issue Jun 18, 2022 · 0 comments

Comments

@buko
Copy link

buko commented Jun 18, 2022

This has bothered me for a while so I thought I might throw it out there:

Our codebase is full (as in overflowing) with Factory objects that create an object in order to make that object available for dependency injection and have empty "public void dispose(T instance)" methods. The objects that these "discardable" Factories create have no special clean-up or disposal logic, they are simply objects that are (1) not aware of the dependency injection machinery and/or (2) require some "configuration logic" (examining system properties, configuration files) in order to be created.

Here's what's a bit frustrating: HK2 will keep Factory instances around, in memory, for the lifetime of the application, just so it can call the empty 'dispose' method. Now it's not exactly the end of the world but it seems to me there should be some way to tell HK2, "Hey, this factory will create the object, but there's no need to keep the factory object instance around forever because once this object is created no special disposal logic is required."

We could simulate this using the InjectionResolver mechanism but... this is basically reinventing the wheel. It seems like a cleaner solution might be to build this functionality into HK2 itself. Spefically I was thinking:

  1. If a Factory object is bound in the @PerLookup scope and it has a @discard annotation then HK2 knows it doesn't need to keep the Factory object around to call dispose(T). Either the application code will take care of disposal or, more than likely, the object provided is immutable and requires no disposal.
  2. Another possibility might be to introduce a subinterface of Factory... DiscardableFactory. The same idea sort of implies. Though I think it's important that such Factories be in the @PerLookup scope. It makes no sense to have a "discardable" Factory in the @singleton scope.

The real problem here BTW is that @PerLookup for Factories is sort of broken. If a @PerLookup Factory provides a @singleton object... that Factory will hang around until the @singleton object is destroyed. This is almost never what we want.

Another way to describe such objects is as "@Unmanaged". That is, you tell the HK2 dependency injection engine, that it doesn't need to need to manage the object lifecycle... because the application will do it. There's no need to invoke @PostConstruct methods or @PreDestroy methods or anything else... the object is fully managed by the application. This idea could apply to more tha just factories -- in fact any object could be marked as @Unmanaged. HK2 would need to know that an @Unmanaged @singleton shouldn't be created more than once -- but SingletonContext would know that during shutdown it doesn't need to destroy an Unmanaged object.

Similarly an @Unmanaged @PerLookup object need never be disposed by the ServiceHandle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant