Hi folks! We discussed abut the implications of EAR deployments for Geronimo and other EE containers quite often already. The problematic area is also described in CDI-18 and CDI-129 in the EG spec issue tracker. In other words: those are not OWB specific issues but rather a lack in the specification itself.
Consider having an EAR with 3 WARs (warA, warB, warC). Each of the WebApplications have per JSR-316 recommendation an own WebApp-ClassLoader whereas the shared EAR libs haven an own ClassLoader forming the parent of the WebApps. Beans in the shared EAR libs are visible in the whole application. But beans from a WEB-INF/lib/*.jar or WEB-INF/classes of warA are obviously not visible to warB and warC. And neither to any shared EAR libs. Other problems arise if e.g a bean in warB @Specialices a bean of a shared EAR lib. In this case the specialiced bean must only get used for warB. The same is true for @Alternatives, Interceptors, etc. Currently most EE containers (Geronimo, JBossAS, Glassfish, ...) only have one single BeanManager which manages the whole EAR. But this is obviously not enough! What we need is a BeanManager tree which is in balance with the ClassLoader hierarchy. That way all the shared EARs would get scanned with a BeanManager which responsibility is only to manage those shared classes. Each WebApplication would get an own BeanManager which has the shared BeanManager as 'parent'. Our MetaDataService SPI might be perfectly fine for this stuff already, we only need to make sure that we don't scan too much classes. For the lookup aspect we'd need to introduce a 'parent-first' lookup with an additional 'DisabledBeans' list. This trick is needed to not pickup Beans which are not enabled anymore in the webapps (they might have been @Specialized by another bean in the WebApp already). wdyt? LieGrue, strub
