[cdi-dev] CDI and generics

[Romain Manni-Bucau]

Just for people who will read this thread later complete Qux class is:

public class Qux extends Baz<String> {

    public Qux(String name) {
    }

}


*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/7/8 Martin Kouba <mkouba at redhat.com>

> Re Arne's question:
> Yes, Baz is a managed bean and AmbiguousResolutionException should not
> be thrown because Qux is not a managed bean (doesn't have a public
> no-arg constructor).
>
> Re Marko's findings:
> Yes, the TCK assertions are not up to date and Baz<T> is not assignable
> to Baz<String>, because String is not assignable from Object (no bound
> is defined -> Object is assumed; see JSL 4.4). So I confirm a TCK issue.
>
> IMO this would deserve a proper cleanup...
>
> Martin
>
> Dne 8.7.2013 01:22, Marko Lukša napsal(a):
> > I'd say it's a bug. While Baz indeed is a managed bean, it shouldn't be
> > injected into injection point with type Baz<String> nor Baz<List<Qux>>.
> > So I believe you're right in saying that this test should fail with
> > UnsatisfiedResolutionException.
> >
> > There was a change made to the spec way back in 2010 (see [1]), but the
> > TCK apparently wasn't updated then. I've filed an issue in the TCK jira
> > [2].
> >
> > The problem isn't only in the TCK, but also in the spec itself. Some of
> > the examples in section 5.2.4 don't conform to the rules defined in the
> > same section (according to the rules, bean Dao<T extends Persistent>
> > shouldn't be eligible for injection into Dao<Order> or Dao<User>). I
> > remember asking about this a year ago ([3]), but I didn't articulate the
> > problem properly.
> >
> > [1]
> >
> https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd05c151f14
> > [2] https://issues.jboss.org/browse/CDITCK-349
> > [3] http://lists.jboss.org/pipermail/cdi-dev/2012-April/001742.html
> >
> > Marko
> >
> > On 7.7.2013 16:04, Arne Limburg wrote:
> >> Hi all,
> >>
> >> At the OpenWebBeans list we are currently discussing handling of
> >> generics in CDI.
> >> I found a test in the CDI 1.1 TCK, which imho has a bug. The test
> >> is
> org.jboss.cdi.tck.tests.inheritance.generics.MemberLevelInheritanceTest
> >> and the (simplified) deployment scenario is the following:
> >>
> >> public class Baz<T> {
> >> }
> >>
> >> public class Qux extends Baz<String> {
> >> }
> >>
> >> @Vetoed
> >> public class Bar<T1, T2> {
> >>   @Inject
> >>   private Baz<T1> baz;
> >>   @Inject
> >>   private Baz<List<T2>> t2BazList;
> >> }
> >>
> >> @RequestScoped
> >> public class Foo extends Bar<String, Qux> {
> >> }
> >>
> >> public class Producer {
> >>   @Produces
> >>   @Amazing
> >>   public String produceString() {
> >>     return "ok";
> >>   }
> >>
> >>   @Produces
> >>   public String[] produceStringArray() {
> >>     return new String[0];
> >>   }
> >>
> >>   @Produces
> >>   public Baz<Baz<Qux>> produceBazBazQux() {
> >>     return new Baz();
> >>   }
> >> }
> >>
> >> The class Bar has some more injection points, but that does not matter.
> >> Due to the TCK this deployment should work, but I don't know how.
> >> Question: Is Baz a Bean (I suppose so) and may it be injected into
> >> Bean Foo, more precisely into the second injection point of class Bar?
> >> - If yes, it also should be injected into the first injection
> >> point, right? This would lead to an AmbiguousResolutionException since
> >> Qux may also be injected into the first injection point.
> >> - If no, the deployment should fail with a
> >> UnsatisfiedResolutionException since there is no Bean that can be
> >> injected into that injection point.
> >>
> >> Is this a bug in the TCK and if not, how is this supposed to work?
> >>
> >> Cheers,
> >> Arne
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20130708/513c2fab/attachment-0001.html