|
||||||||
|
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 |
||||||||
|
||||||||
|
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 |
||||||||
First CDI is a Java EE technology and relies on its module architecture. Also it does not define SE support at the moment (although both Weld and OWB do support SE in its own way) - this will be likely addressed in CDI 2, see also CDI-160. However even Java SE does not define any "module system" yet.
In this scenario OWB finds org.jboss.weld.environment.se.WeldSEBeanRegistrant extension on the classpath and delivers AfterBeanDiscovery event. However this extension is weld-specific and expects Weld to be initialized (which is not).
Weld could probably add some workaround for this specific issue but i don't think it would protect your system from the "classloading hell". Instead I would rely on some modular system for SE (JBoss Modules, OSGi, etc.) so that each module has its own isolated ClassLoader.
Note that there's an effort to integrate CDI in OSGi environments - RFP 146, see also the reference implementation Pax CDI.