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
>>
>>
>> .
>>
