You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: