There are a handful of services that HK2 will instantiate as SOON as
they are discovered. In the case of injection resolvers we found that
if we do NOT do this then we very often end up in deadlock or cyclic
reference problems.
In order to solve your issue I would recommend that your
InjectionResolver implementation inject using a javax.inject.Provider or
an IterableProvider
<
https://hk2.java.net/2.3.0-b09/apidocs/org/glassfish/hk2/api/IterableProvider.html>.
This will allow HK2 to instantiate the InjectionResolver early but will
not cause any of the underlying services that you need to be created.
On 6/24/2014 10:42 PM, buko wrote:
> Trying to implement a system where ServiceLocator is built piece-meal.
> During an initial bootstrap phase some core modules are added, then
> during a configure phase more binders are added (using
> ServiceLocatorUtilities.bind(serviceLocator, binder...), and finally
> during an interactive phase yet more modules are bounded.
>
> Was surprised to discover that hk2 doesn't really support this... it
> seems when new configuration is added, ServiceLocator.reup() will
> invoke ServiceLocator.reupInjectionResolvers(), which will actually
> instantiate InjectionResolvers and put them in a map. Of course once
> injection resolvers are created that can trigger the creation of all
> sorts of other objects.
>
> I'm wondering if this is really desirable behavior? Would it make
> sense to instantiate injection resolvers lazily until the system is
> actually called upon to resolve dependencies for a given injection point?
>
> If so I'll toss a feature request into the backlog...