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