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