[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ] 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. -- This message was sent by Atlassian JIRA (v6.3.1#6329)