Good catch. We need a getInjectionPoint().getType() check on https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injectionpoint/dynamic/DynamicInjectionPointTest.java#L99
On Mon, Sep 11, 2017 at 3:23 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Surely the one to test: > > https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injectionpoint/dynamic/DynamicInjectionPointTest.java > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2017-09-11 9:20 GMT+02:00 Arne Limburg <arne.limb...@openknowledge.de>: > > > I'm with Mark here, > > > > InjectionPoint#getType() should return a ParameterizedType Instance<Foo> > > > > So in the code below we simply should return parameterizedType I think. > > > > Would that pass the TCK? If yes, we definitely should file a TCK issue, > > there seems to be a test missing. > > > > > > Cheers, > > > > Arne > > > > ________________________________ > > Von: Mark Struberg <strub...@yahoo.de.INVALID> > > Gesendet: Montag, 11. September 2017 09:04:41 > > An: openwebbeans-dev > > Betreff: Re: Odd behavior in InjectionPointProducer > > > > Hmm, if you have a class > > > > public class Bla { > > private @Inject Instance<Foo> myInstance; > > } > > > > then I'd asssume that the InjectionPoint.getType for myInstance would be > > Instance<Foo> and not Foo alone. > > > > > The problem is that Bean.getBeanClass() can never be null, by > definition, > > > but also should not be used for type safe resolution (we actually had a > > > discussion about this on the EG list as I had the opposite belief). > > > > Yes, there was a discussion which never got finished... > > > > Weld guys assume that they can infere the proxy type of a bean just by > > getTypes(). > > I don't believe that. Especially if @Typed is involved or if the real > > AnnotatedType got modified then it is definitely not possible. > > At least it's pretty expensive to detect. Would get my head around it > > again tbh. > > > > In OWB we introduced an own method getReturnType() in OwbBean. > > This get's evaluated and cached based on a few criteria. > > Most of the time it simply uses the getBeanClass() type. > > > > I'll have to dig deeper into your sample to understand what you wanted to > > do with it. > > > > Could you probably put your use case in an OWB unit test and ship it as > > patch? > > > > The only thing you have to do is to extend AbstractUnit test and then > use: > > startcontainer(ClassX.class, ClassY.class, ...); > > > > > > txs and LieGrue, > > strub > > > > > > > > > > LieGrue, > > strub > > > > > Am 10.09.2017 um 22:54 schrieb John D. Ament <johndam...@apache.org>: > > > > > > Hi, > > > > > > I'm running some tests locally using OWB and Instance objects. I > noticed > > > that when the injection point is Instance<Foo> and I attempt to get an > > > injectable reference to the InjectionPoint, I get a very odd value for > > > InjectionPoint.getType(). As far as I understand it, this value should > > be > > > the type being injected into, e.g. Foo in my case. What I actually get > > > back is the value of Bean.getBeanClass(). That makes very little > sense. > > > As best as I can tell, the following code snippet is the cause: > > > > > > if (ParameterizedType.class.isInstance(type)) > > > { > > > ParameterizedType parameterizedType = > > > ParameterizedType.class.cast(type); > > > if (parameterizedType.getRawType() == Instance.class) > > > { > > > Bean<InjectionPoint> bean = > > > creationalContextImpl.getBean(); > > > return new InjectionPointDelegate( > > > injectionPoint, > > > bean.getBeanClass() != null ? > > > bean.getBeanClass() : parameterizedType.getActualTypeArguments()[0]); > > > } > > > } > > > > > > The problem is that Bean.getBeanClass() can never be null, by > definition, > > > but also should not be used for type safe resolution (we actually had a > > > discussion about this on the EG list as I had the opposite belief). > But > > I > > > do believe that the else value is in fact what should always be used, I > > > always should be getting the expected parameterized value. > > > > > > If you guys agree, I can submit a patch to fix this. > > > > > > John > > > > > > . > > >
