[DISCUSS] implement a hierarchic BeanManager?

[Mark Struberg <st...@yahoo.de>]

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

Re: [DISCUSS] implement a hierarchic BeanManager?

[David Jencks <da...@yahoo.com>]

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 <st...@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

Re: [DISCUSS] implement a hierarchic BeanManager?

[Joseph Bergmark <be...@apache.org>]

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 <st...@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