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/B... > > 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... > > 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(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. > _______________________________________________ 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.

please create a new spec issue. This should be definitely clarified.

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/B... >> >> 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... >> >> 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(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. >> > _______________________________________________ > 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

On 12.8.2015 11:07, arjan tijms wrote:

I think this is a bug. Even if getTypes() returns AbstractClass only, you should still be able to call all the methods of AbstractClass (including those that come from Interface) and therefore, the proxy class generator should be generating these. I filed https://issues.jboss.org/browse/WELD-2010 for Weld.