Re: Odd behavior in InjectionPointProducer

[John D. Ament]

Ok, I was able to get a decent reproducer on this, wrote up my notes in
https://issues.apache.org/jira/browse/OWB-1216

John

On Mon, Sep 11, 2017 at 8:21 AM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> Well, the IP resolving is always done against getTypes().
> But I think this is uninamously understood the same in all impls, isn't?
>
> The only discussion I remembered was around the getTypes() vs
> getBeanClass() for proxing. Thus my answers.
>
> Again: test would be cool, then we could help much faster.
>
> txs and LieGrue,
> strub
>
>
> > Am 11.09.2017 um 12:36 schrieb John D. Ament <johndam...@apache.org>:
> >
> > So remember.  The question here is about injection point, not the bean
> > type.  Some of the problems described are deployment problems.  E.g. you
> > try to inject using a type that's forbidden because of @Typed, then that
> > should result in UnsatisfiedDependencies, at deployment time.
> >
> > On Mon, Sep 11, 2017 at 6:07 AM Arne Limburg <
> arne.limb...@openknowledge.de>
> > wrote:
> >
> >> Yes, that's interesting, you could get a proxy that directly extends
> >> Object. So you could invoke no method on that bean (except toString(),
> >> equals(...), hashCode(), ...)
> >>
> >>
> >> Does not seem to be usefull at all
> >>
> >> ________
> >> Von: Mark Struberg <strub...@yahoo.de.INVALID>
> >> Gesendet: Montag, 11. September 2017 11:13:20
> >> An: openwebbeans-dev
> >> Betreff: Re: Odd behavior in InjectionPointProducer
> >>
> >> yes I'm also really sure it must get resolved as per the spec.
> >> The question is just which proxy you get once there is also a normal
> scope
> >> on the class
> >>
> >>
> >> @Named
> >> @Typed
> >> @ApplicationScoped
> >> public class MyBla extends SomeComplicatedThing implements
> AFewInterfaces {
> >> ...
> >> }
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 11.09.2017 um 09:41 schrieb Arne Limburg <
> >> arne.limb...@openknowledge.de>:
> >>>
> >>> Quick look into the spec
> >> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#name_resolution
> >>>
> >>> @Named
> >>>
> >>> @Typed()
> >>>
> >>> seems to be valid and the bean should be found by EL.
> >>>
> >>> 
> >>> Von: Romain Manni-Bucau <rmannibu...@gmail.com>
> >>> Gesendet: Montag, 11. September 2017 09:31:38
> >>> An: openwebbeans-dev
> >>> Betreff: Re: Odd behavior in InjectionPointProducer
> >>>
> >>> Not sure it is 100% related but looks like a bean without types so not
> >> even
> >>> sure @Named should be "matchable" since you dont match types at all (we
> >>> often used @Typed = @Vetoed in CDI 1.0)
> >>>
> >>>
> >>> 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:29 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >>>
> >>>> Btw, what I've seen quite a few times is the following:
> >>>>
> >>>> @Named
> >>>> @Typed()
> >>>> public class MyBla extends SomeComplicatedThing implements
> >> AFewInterfaces {
> >>>> ...
> >>>> }
> >>>>
> >>>> Means the @Typed got purely used to not have it picked up by type but
> >> only
> >>>> via EL.
> >>>> And in that case the proxy in Weld is most likely not working?
> >>>> Is this a valid use case?
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 11.09.2017 um 09:23 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> Surely the one to test:
> >>>>> https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/
> >>>> main/java/o

Re: Odd behavior in InjectionPointProducer

[Mark Struberg]

Well, the IP resolving is always done against getTypes().
But I think this is uninamously understood the same in all impls, isn't?

The only discussion I remembered was around the getTypes() vs getBeanClass() 
for proxing. Thus my answers.

Again: test would be cool, then we could help much faster.

txs and LieGrue,
strub


> Am 11.09.2017 um 12:36 schrieb John D. Ament <johndam...@apache.org>:
> 
> So remember.  The question here is about injection point, not the bean
> type.  Some of the problems described are deployment problems.  E.g. you
> try to inject using a type that's forbidden because of @Typed, then that
> should result in UnsatisfiedDependencies, at deployment time.
> 
> On Mon, Sep 11, 2017 at 6:07 AM Arne Limburg <arne.limb...@openknowledge.de>
> wrote:
> 
>> Yes, that's interesting, you could get a proxy that directly extends
>> Object. So you could invoke no method on that bean (except toString(),
>> equals(...), hashCode(), ...)
>> 
>> 
>> Does not seem to be usefull at all
>> 
>> 
>> Von: Mark Struberg <strub...@yahoo.de.INVALID>
>> Gesendet: Montag, 11. September 2017 11:13:20
>> An: openwebbeans-dev
>> Betreff: Re: Odd behavior in InjectionPointProducer
>> 
>> yes I'm also really sure it must get resolved as per the spec.
>> The question is just which proxy you get once there is also a normal scope
>> on the class
>> 
>> 
>> @Named
>> @Typed
>> @ApplicationScoped
>> public class MyBla extends SomeComplicatedThing implements AFewInterfaces {
>> ...
>> }
>> 
>> 
>> LieGrue,
>> strub
>> 
>>> Am 11.09.2017 um 09:41 schrieb Arne Limburg <
>> arne.limb...@openknowledge.de>:
>>> 
>>> Quick look into the spec
>> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#name_resolution
>>> 
>>> @Named
>>> 
>>> @Typed()
>>> 
>>> seems to be valid and the bean should be found by EL.
>>> 
>>> 
>>> Von: Romain Manni-Bucau <rmannibu...@gmail.com>
>>> Gesendet: Montag, 11. September 2017 09:31:38
>>> An: openwebbeans-dev
>>> Betreff: Re: Odd behavior in InjectionPointProducer
>>> 
>>> Not sure it is 100% related but looks like a bean without types so not
>> even
>>> sure @Named should be "matchable" since you dont match types at all (we
>>> often used @Typed = @Vetoed in CDI 1.0)
>>> 
>>> 
>>> 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:29 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
>>> 
>>>> Btw, what I've seen quite a few times is the following:
>>>> 
>>>> @Named
>>>> @Typed()
>>>> public class MyBla extends SomeComplicatedThing implements
>> AFewInterfaces {
>>>> ...
>>>> }
>>>> 
>>>> Means the @Typed got purely used to not have it picked up by type but
>> only
>>>> via EL.
>>>> And in that case the proxy in Weld is most likely not working?
>>>> Is this a valid use case?
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>>> Am 11.09.2017 um 09:23 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>>>>> :
>>>>> 
>>>>> 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

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

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
> >
> > 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 myInstance;
> > }
> >
> > then I'd asssume that the InjectionPoint.getType for myInstance would be
> > Instance 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 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 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
> >
> >
> > .
> >
>

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

So remember.  The question here is about injection point, not the bean
type.  Some of the problems described are deployment problems.  E.g. you
try to inject using a type that's forbidden because of @Typed, then that
should result in UnsatisfiedDependencies, at deployment time.

On Mon, Sep 11, 2017 at 6:07 AM Arne Limburg <arne.limb...@openknowledge.de>
wrote:

> Yes, that's interesting, you could get a proxy that directly extends
> Object. So you could invoke no method on that bean (except toString(),
> equals(...), hashCode(), ...)
>
>
> Does not seem to be usefull at all
>
> 
> Von: Mark Struberg <strub...@yahoo.de.INVALID>
> Gesendet: Montag, 11. September 2017 11:13:20
> An: openwebbeans-dev
> Betreff: Re: Odd behavior in InjectionPointProducer
>
> yes I'm also really sure it must get resolved as per the spec.
> The question is just which proxy you get once there is also a normal scope
> on the class
>
>
> @Named
> @Typed
> @ApplicationScoped
> public class MyBla extends SomeComplicatedThing implements AFewInterfaces {
> ...
> }
>
>
> LieGrue,
> strub
>
> > Am 11.09.2017 um 09:41 schrieb Arne Limburg <
> arne.limb...@openknowledge.de>:
> >
> > Quick look into the spec
> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#name_resolution
> >
> > @Named
> >
> > @Typed()
> >
> > seems to be valid and the bean should be found by EL.
> >
> > ____
> > Von: Romain Manni-Bucau <rmannibu...@gmail.com>
> > Gesendet: Montag, 11. September 2017 09:31:38
> > An: openwebbeans-dev
> > Betreff: Re: Odd behavior in InjectionPointProducer
> >
> > Not sure it is 100% related but looks like a bean without types so not
> even
> > sure @Named should be "matchable" since you dont match types at all (we
> > often used @Typed = @Vetoed in CDI 1.0)
> >
> >
> > 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:29 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >
> >> Btw, what I've seen quite a few times is the following:
> >>
> >> @Named
> >> @Typed()
> >> public class MyBla extends SomeComplicatedThing implements
> AFewInterfaces {
> >> ...
> >> }
> >>
> >> Means the @Typed got purely used to not have it picked up by type but
> only
> >> via EL.
> >> And in that case the proxy in Weld is most likely not working?
> >> Is this a valid use case?
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 11.09.2017 um 09:23 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 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
> >>>>
> >>>> 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. Septem

Re: Odd behavior in InjectionPointProducer

[John D. Ament]

On Mon, Sep 11, 2017 at 3:05 AM Mark Struberg 
wrote:

> Hmm, if you have a class
>
> public class Bla {
>   private @Inject Instance myInstance;
> }
>
> then I'd asssume that the InjectionPoint.getType for myInstance would be
> Instance and not Foo alone.
>
>
Agreed, simply trying to make sense of what the code's trying to do.


> > 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 :
> >
> > Hi,
> >
> > I'm running some tests locally using OWB and Instance objects.  I noticed
> > that when the injection point is Instance 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 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
>
>
> .
>

Re: Odd behavior in InjectionPointProducer

[Romain Manni-Bucau]

Not sure it is 100% related but looks like a bean without types so not even
sure @Named should be "matchable" since you dont match types at all (we
often used @Typed = @Vetoed in CDI 1.0)


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:29 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> Btw, what I've seen quite a few times is the following:
>
> @Named
> @Typed()
> public class MyBla extends SomeComplicatedThing implements AFewInterfaces {
> ...
> }
>
> Means the @Typed got purely used to not have it picked up by type but only
> via EL.
> And in that case the proxy in Weld is most likely not working?
> Is this a valid use case?
>
> LieGrue,
> strub
>
> > Am 11.09.2017 um 09:23 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > 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
> >>
> >> 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 myInstance;
> >> }
> >>
> >> then I'd asssume that the InjectionPoint.getType for myInstance would be
> >> Instance 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 and I attempt to get an
> >>> injectable reference to the Inje

Re: Odd behavior in InjectionPointProducer

[Mark Struberg]

Btw, what I've seen quite a few times is the following:

@Named
@Typed() 
public class MyBla extends SomeComplicatedThing implements AFewInterfaces {
...
}

Means the @Typed got purely used to not have it picked up by type but only via 
EL.
And in that case the proxy in Weld is most likely not working?
Is this a valid use case?

LieGrue,
strub

> Am 11.09.2017 um 09:23 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:
> 
> 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
>> 
>> 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 myInstance;
>> }
>> 
>> then I'd asssume that the InjectionPoint.getType for myInstance would be
>> Instance 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 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 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
>> 
>> 
>> .
>> 

Re: Odd behavior in InjectionPointProducer

[Romain Manni-Bucau]

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
>
> 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 myInstance;
> }
>
> then I'd asssume that the InjectionPoint.getType for myInstance would be
> Instance 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 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 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
>
>
> .
>

Re: Odd behavior in InjectionPointProducer

[Mark Struberg]

Hmm, if you have a class

public class Bla {
  private @Inject Instance myInstance;
}

then I'd asssume that the InjectionPoint.getType for myInstance would be 
Instance 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 :
> 
> Hi,
> 
> I'm running some tests locally using OWB and Instance objects.  I noticed
> that when the injection point is Instance 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 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


.

Re: Odd behavior in InjectionPointProducer

[Romain Manni-Bucau]

Hmm

Does it passes TCK with your patch? Also wonder if we shouldnt get the impl
in some cases vs the signature. If tck are green im ok with it.

Le 10 sept. 2017 22:54, "John D. Ament"  a écrit :

> Hi,
>
> I'm running some tests locally using OWB and Instance objects.  I noticed
> that when the injection point is Instance 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 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
>