This seems like a good idea. I'd only note that geronimo has a single classloader per ear so obviously we don't key per-app-module stuff off the classloader. However, OWB supports plugging in a different "keying" system. You implement a SingletonService<WebBeansContext> and install it with WebBeansFinder.setSingletonService(INSTANCE);. Then you need in the app server infrastructure to notify the singleton service when you enter and leave a context such as web app or ejb module.
thanks david jencks On Feb 14, 2012, at 6:16 AM, Joseph Bergmark wrote: > 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 <[email protected]> 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
