Thanks, I eventually figured this out (after way too much time stepping
through the code). It seems like it's not enough to just register the
InjectionResolvers first -- you have to create the ServiceLocator (and
commit the config transaction) and then bind the other stuff later in a
sequential config transaction.
In retrospect it seems like a really bad idea to have to have analysis
based on the runtime-state of the ServiceLocator. It introduces very
unsubtle and unclear dependencies. Are there any other places where
analysis decisions are driven off of runtime state?
> I believe we will be doing another drop of hk2 sometime this week.
I'd like to pick this up. Could we get an announcement on the list when
this is available?
On Mon, May 19, 2014 at 7:07 AM, John Wells <john.wells_at_oracle.com> wrote:
> Yes, this is true. What you need to do is register your injection
> resolver *before* adding in the one you want to do with automatic analysis
> OR you can wait for the next release of hk2 (because we had already noticed
> this problem) and use the annotation:
>
> @InjectionPointIndicator
>
> on the annotation you are using as your custom injection annotation. If
> you put that on your custom annotation then you can use automatic analysis
> BEFORE you add in the injection resolver.
>
> However, this feature will not be available until the next release of hk2
> since it was just added last week. I believe we will be doing another drop
> of hk2 sometime this week.
>
>
> On 5/19/2014 12:16 AM, buko wrote:
>
> The bug seems to have to do with the fact that
> ServiceLocator.isInjectorAnnotation is returning false because it's not yet
> aware of the registered injection resolvers (they don't show up in the
> allResolvers map). Could this be some sort of ordering issue?
>
>
> On Sun, May 18, 2014 at 12:11 PM, buko <buko_at_chiubarobot.com> wrote:
>
>>
>> Looks like another bug: if I use addActiveDescriptor (from within
>> AbstractBinder) then custom injection annotations (which have a custom
>> injection resolver bound elsewhere) don't actually get resolved. They seem
>> to be completely ignored. The annotated variables end up null and the
>> injection resolvers are ignored. Going back to the bind() syntax works
>> fine.
>>
>>
>
>