Hi,
On Mon, Aug 10, 2015 at 8:41 AM, Martin Kouba <mkouba(a)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...
@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/f24c5...
>
> 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(a)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