In any case the javadoc for InjectionResolver should be enhanced to
contain this information, as otherwise it comes as a surprise!
On 6/25/2014 5:45 PM, john wells wrote:
> 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...
>