Thanks for entering a Jira on this
On 6/5/2014 10:11 PM, buko wrote:
> Just encountered this bug again. I can't pin it down. In this case
> there's an interface:
>
> @Contract
> interface Adapter<A, B> {}
>
> an abstract class
>
> abstract class AbstractAdapter<A,B> implements Adpater<A, B> { ... }
>
> And several subclasses. addActiveDescriptor fails consistently to
> inject these sub-classes via the interface ie @Inject Adapter<Foo,
> Bar> fooAdapter. Changing the binding to using the binding dsl (ie
> bind(SubAdapter.class).to(new TypeLiteral<>)) ... and it magically
> works. Is this expected behavior?
>
> But here's an interesting work around: remove the Abstract class from
> the equation and implement the interface directly and
> addActiveDescriptor works again. Magic?
>
> Something is getting lost due to the presence of the base class.
> Likely hk2 is picking up the type variable parameters when generics
> and inheritance the mix. I've encountered similar problems with
> reflection and generics and inheritance. A project that solves this
> problem -- how to pick out the right type type variables from a
> hierarchy -- is typetools ( https://github.com/jhalterman/typetools ).
> May want to take a look at that magic...
>
>
>
> On Wed, May 28, 2014 at 5:53 AM, John Wells <john.wells_at_oracle.com
> <mailto:john.wells_at_oracle.com>> wrote:
>
> It is possible that this is true. Could you enter a Jira on this
> issue? (https://java.net/jira/browse/HK2)
>
> Thanks!
>
>
> On 5/27/2014 12:48 AM, buko wrote:
>
>
> Seems like there's a bug with addActiveDescriptor and
> ContractsProvided. If you use it on a generic interface it
> doesn't actually seem to detect that one of the contracts is a
> generic interface and bind it appropriately so attempts to
> @Inject the binding later fails. If you normally bind it,
> using the TypeLiteral syntax (bind(A).to(new
> TypeLiteral<B<C>>)) ... then attempts to inject B<C> will work.
>
> Seems like ContractsProvided ought to handle this?
>
>
>