[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
(v6.3.1#6329)


More information about the cdi-dev mailing list