[cdi-dev] Bean<T> that only qualifies super types?

[Martin Kouba]

Dne 7.8.2015 v 14:18 arjan tijms napsal(a):
> Hi,
>
> On Fri, Aug 7, 2015 at 1:48 PM, Martin Kouba <mkouba at redhat.com> wrote:
>> No, an interface may be a bean type but not a bean class of a managed bean.
>> For producer methods, the getBeanClass() returns the bean class of the bean
>> that declares the producer method.
>>
>> The bean class is defacto an implementation class.
>
> Seems fair enough, but if I look at the build-in Bean<T>
> implementations of Weld, then org.jboss.weld.Bean.RIBean returns the
> type as the bean class. See:

Built-in beans are handled specially in Weld.

>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld/weld-core-impl/2.2.12.Final/org/jboss/weld/bean/RIBean.java#56
>
> If we look at a concrete implementation, say HttpServletRequestBean
>
> (see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/ee/HttpServletRequestBean.java#HttpServletRequestBean)
>
> Then HttpServletRequest.class is passed to the super ctor as the Type,
> and therefor also becomes the bean class, as per RIBean.java#56.

Not really. HttpServletRequestBean also extends AbstractBuiltInBean and 
so the getBeanClass() method returns the HttpServletRequestBean.class. 
See also:
http://probe-weld.itos.redhat.com/weld-numberguess/weld-probe#/bean/f24c5153-d823-366c-bdc9-c3e1a6eb0812

>
> Same thing for UserTransaction, Principal, ServletRequest, etc.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>>
>>>
>>> There's nothing wrong with that, is it?
>>>
>>> So by extension, is this wrong then?
>>>
>>> @Produces
>>> public Foo produce() {
>>>      return new FooImpl();
>>> }
>>
>>
>> This is OK. But the bean class of this producer is not Foo as mentioned
>> above.
>>
>>
>>>
>>>
>>>
>>>> No, this is not possible. Qualifiers are tied to a bean definition, not
>>>> to a
>>>> bean type.
>>>
>>>
>>> So this would possibly be an enhancement or new feature request then.
>>>
>>>
>>> I did found a workaround though, which seems to work because the Type
>>> I'd like to hide happens to have generic parameters:
>>>
>>> private static class Dummy {}
>>>
>>> @Override
>>> public Set<Type> getTypes() {
>>>       return new HashSet<Type>(asList(Foo.class,
>>> ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class,
>>> Dummy.class})));
>>> }
>>>
>>> With those types the proxy that's generated contains methods for both
>>> Foo and Map, but because the generic parameters are the private class,
>>> the client application can never declare an injection point for this
>>> (certain not accidentally).
>>>
>>> Another possible workaround I thought of is using a second Bean<T>
>>> that only has Foo as its type and is @Dependent scoped, which then
>>> asks the bean manager for an instance of a qualified Foo (qualifier is
>>> of a private type). If I'm not mistaken the first Bean<T> would then
>>> be called and an @RequestScoped proxy would be returned, which the
>>> second Bean<T> can then return from its create() method.
>>>
>>> What do you think, any of these methods have potential unforeseen
>>> side-effects or are they safe to use?
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>>>> code under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual
>>>>> property rights inherent in such information.
>>>>>
>>>>
>>>> --
>>>> Martin Kouba
>>>> Software Engineer
>>>> Red Hat, Czech Republic
>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic