[cdi-dev] getBeanClass return value for build-in beans?

arjan tijms arjan.tijms at gmail.com
Wed Aug 12 05:07:51 EDT 2015


Hi Martin,

On Wed, Aug 12, 2015 at 10:22 AM, Martin Kouba <mkouba at redhat.com> wrote:
> please create a new spec issue. This should be definitely clarified.

I'll do that, thanks!

Kind regards,
Arjan Tijms



>
> Thanks,
> Martin
>
> Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):
>
>> Hi Arjan,
>>
>> the bean class in CDI is used for two purposes:
>>
>> 1) to identify the bean archive the bean belongs to (this is crucial for
>> inter-module injection)
>> 2) if the bean is an alternative, interceptor or decorator the bean
>> class is used for matching with beans.xml enablement entries
>>
>> Other than these, there are no restrictions imposed by the spec. Note
>> that there is absolutely no requirement that the bean class is part of
>> the bean types (as demonstrated by producer method/fields for example).
>>
>> Therefore, you are free to use any class as a bean class that:
>> 1) properly identifies the bean archive (i.e. is located in the bean
>> archive where you want the custom bean to belong)
>> 2) if the bean is an alternative, interceptor or decorator then choose
>> the class whose name you want people to put to beans.xml when enabling it
>>
>> What you indicated in the previous e-mails - that Weld does not work
>> properly if the bean class is an abstract class looks like a bug in Weld
>> that I will be investigating.
>>
>> HTH,
>>
>> Jozef
>>
>>
>>
>> On 11.8.2015 12:26, arjan tijms wrote:
>>>
>>> Hi,
>>>
>>> This is split-off from the thread "Bean<T> that only qualifies super
>>> types?", where the question came up what a Bean<T> should return from
>>> the getBeanClass() method for the case of build-in beans.
>>>
>>> The JavaDoc for getBeanClass() currently says the following:
>>>
>>> "The bean class of the managed bean or session bean or of the bean
>>> that declares the producer method or field."
>>>
>>> See:
>>> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
>>>
>>> The case where a Bean<T> instance is directly created and added as
>>> bean to AfterBeanDiscovery in an extension does not seem to be covered
>>> by this documentation.
>>>
>>> Weld returns "this.class" here.
>>>
>>> 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
>>>
>>> Is that what build-in beans should always do, and if so, should the
>>> JavaDoc/spec be clarified for this?
>>>
>>> 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.
>>>
>> _______________________________________________
>> 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


More information about the cdi-dev mailing list