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

[arjan tijms]

Hi,

On Mon, Aug 10, 2015 at 8:41 AM, Martin Kouba <mkouba at redhat.com> wrote:
> Built-in beans are handled specially in Weld.

Okay, but if another spec wants to provide build-in beans (in this
case it concerns JSF 2.3), should it also do special things?

> Not really. HttpServletRequestBean also extends AbstractBuiltInBean and so
> the getBeanClass() method returns the HttpServletRequestBean.class.

I see, thanks for the pointer. After taking a closer look it appeared
that AbstractDecorableBuiltInBean is the one containing an overloaded
getBeanClass method. See
http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71

@Override
public Class<?> getBeanClass() {
    return getClass();
}

Is this the recommended thing to do for build-in (spec provided)
beans? Should getBeanClass simply always return getClass()?  The spec
and JavaDoc aren't overly clear about this point.

Thanks for your help!

Kind regards,
Arjan Tijms







 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