Today, I also struggled with this problem but with session beans on Glassfish 3.1.2.2 with Weld 1.1.8.Final
Deployment success depends on the order in which the HashSet<Type> collection will be filled at org.jboss.weld.bean.SessionBean.initTypes() where it is assigned to the field super.types.
Source of the problem is the org.jboss.weld.util.reflection.HierarchyDiscovery.getTypeMap() method, called from org.jboss.weld.bean.SessionBean.initTypes(), which returns the extra information that is not relevant to the class hierarchy of a bean.
And I was about to fill a bug. But the search immediately brought link here. By the way, the use of @Typed help solve my problem.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Today, I also struggled with this problem but with session beans on Glassfish 3.1.2.2 with Weld 1.1.8.Final
Deployment success depends on the order in which the HashSet<Type> collection will be filled at org.jboss.weld.bean.SessionBean.initTypes() where it is assigned to the field super.types.
Source of the problem is the org.jboss.weld.util.reflection.HierarchyDiscovery.getTypeMap() method, called from org.jboss.weld.bean.SessionBean.initTypes(), which returns the extra information that is not relevant to the class hierarchy of a bean.
And I was about to fill a bug. But the search immediately brought link here. By the way, the use of @Typed help solve my problem.