You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "John D. Ament" <jo...@apache.org> on 2017/09/10 20:54:27 UTC
Odd behavior in InjectionPointProducer
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
Re: Odd behavior in InjectionPointProducer
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <jo...@apache.org> a écrit :
> 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
>
Re: Odd behavior in InjectionPointProducer
Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@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 <jo...@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.limburg@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 <st...@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.limburg@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 <rm...@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 <st...@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 <
> >> rmannibucau@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.limburg@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 <st...@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 <
> johndament@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
> >>>>>>
> >>>>>>
> >>>>>> .
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Odd behavior in InjectionPointProducer
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@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 <ar...@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 <st...@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.limburg@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 <rm...@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 <st...@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 <
>> rmannibucau@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.limburg@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 <st...@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 <johndament@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
>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>
>>>>
>>
>>
Re: Odd behavior in InjectionPointProducer
Posted by "John D. Ament" <jo...@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 <ar...@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 <st...@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.limburg@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 <rm...@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 <st...@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 <
> rmannibucau@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.limburg@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 <st...@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 <johndament@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
> >>>>
> >>>>
> >>>> .
> >>>>
> >>
> >>
>
>
AW: Odd behavior in InjectionPointProducer
Posted by Arne Limburg <ar...@openknowledge.de>.
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 <st...@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 <ar...@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 <rm...@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 <st...@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 <rmannibucau@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 <ar...@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 <st...@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 <jo...@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
>>>>
>>>>
>>>> .
>>>>
>>
>>
Re: Odd behavior in InjectionPointProducer
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <ar...@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 <rm...@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 <st...@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 <rmannibucau@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 <ar...@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 <st...@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 <jo...@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
>>>>
>>>>
>>>> .
>>>>
>>
>>
AW: Odd behavior in InjectionPointProducer
Posted by Arne Limburg <ar...@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 <rm...@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 <st...@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 <rmannibucau@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 <ar...@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 <st...@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 <jo...@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
> >>
> >>
> >> .
> >>
>
>
Re: Odd behavior in InjectionPointProducer
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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 <rmannibucau@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 <ar...@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 <st...@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 <jo...@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
> >>
> >>
> >> .
> >>
>
>
Re: Odd behavior in InjectionPointProducer
Posted by Mark Struberg <st...@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 <rm...@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 <ar...@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 <st...@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 <jo...@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
>>
>>
>> .
>>
Re: Odd behavior in InjectionPointProducer
Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@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 <ar...@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 <st...@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 <jo...@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
> >
> >
> > .
> >
>
Re: Odd behavior in InjectionPointProducer
Posted by Romain Manni-Bucau <rm...@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 <ar...@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 <st...@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 <jo...@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
>
>
> .
>
AW: Odd behavior in InjectionPointProducer
Posted by Arne Limburg <ar...@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 <st...@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 <jo...@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
.
Re: Odd behavior in InjectionPointProducer
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Sep 11, 2017 at 3:05 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> 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.
>
>
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 <jo...@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
>
>
> .
>
Re: Odd behavior in InjectionPointProducer
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@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
.