I agree, at the very minimum some way to associate bean managers as having visibility into each other would allow us to build more complex relationships.
In your example below, all 3 wars would have visibility into shared jars in ear/lib, but have their own unique web-inf/lib jars. This mostly works now, given that we key things off of the Classloader. If we share the contexts (which are also looked by up class loader, so you have to change that) then it pretty much works. Where things start to fall apart a bit are ejb-jars in the ear. In some servers those jars share a single class loader, but they can be started/stopped individually, which makes it difficult to key things like BeanManagers & Lifecycles to the class loader that they all share. We need to be able to start/stop them individually, but still somehow expose the fact that they have visibility into each others classes. Sincerely, Joe On Mon, Feb 13, 2012 at 4:45 PM, Mark Struberg <strub...@yahoo.de> wrote: > 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
