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

[arjan tijms]

Hi,

On Wed, Aug 12, 2015 at 10:10 AM, Jozef Hartinger <jharting at redhat.com> wrote:
> 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)

In this particular case it concerns the javax.faces.jar for JSF 2.3.
Some vendors split up this archive in two, an API jar and an impl, jar
(although for JSF 2.3 we don't really encourage this). Therefor it
looks like it does make a difference if the Bean<T> implementation
will return this.class (an implementation type, like Weld does) or say
Flash.class (an API class).

> 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.

I'm not 100% sure what the intend is. Is the proxy supposed to only
implement methods of the Types that are returned by the Bean<T>
implementation, or should it be smart enough to look at the super
types of whatever Type is returned?

So given:

public abstract class AbstractClass implements Interface { ... }

If getTypes returns only Abstract.class, then only the methods defined
by AbstractClass itself are implemented by the proxy. Those from
Interface throw exceptions when called.

If getTypes returns both Abstract.class and Interface.class, then all
methods defined by AbstractClass and Interface are implemented by the
proxy.

Is this how things should be, or should the proxy generator see for
itself that AbstractClass implements Interface?

Kind regards,
Arjan Tijms


>
> 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.
>>
>