[cdi-dev] [JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition

Mark Struberg (JIRA) issues at jboss.org
Mon Sep 8 03:51:01 EDT 2014

    [ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999733#comment-12999733 ] 

Mark Struberg commented on CDI-456:

to also add what we discussed on IRC on friday:

Bean#getBeanClass() is _only_ defined for 'Managed Beans' at the moment. That means it is only defined for classes which get scanned at boot time.  It is *not* defined for anything you do via Extensions.

regarding the modularity discussion: yes, using getBeanClass() for that would work for ManagedBeans which get scanned by the container, but again: it wont work for 3 custom Bean<T> which are differently configured for each of the 3 WARs. Especially since getBeanClass() might return null if you strictly follow the spec wording. 

So I think we need to 
a.) clarify what getBeanClass() shall return for Bean<T> added via Extensions
b.) how modularity works for synthetic beans.

The whole modularity in EAR otoh requires that JavaEE FINALLY properly defines the default isolation (EAR as 1 classloader + each WAR as child ClassLoader, etc) as standard. If the EE platform doesn't have a proper modularity specification we have a floating target and cannot define how CDI should handle it neither.

> fix Bean#getBeanClass() definition
> ----------------------------------
>                 Key: CDI-456
>                 URL: https://issues.jboss.org/browse/CDI-456
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>            Reporter: Mark Struberg
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit. 
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.

This message was sent by Atlassian JIRA

More information about the cdi-dev mailing list