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

[arjan tijms]

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:

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.

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