geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: rfc66 fun
Date Wed, 20 Jan 2010 19:50:22 GMT
On 1/20/2010 2:38 PM, Jarek Gawor wrote:
> Hey,
> For last few days I've been looking into getting the rfc66 extender
> going in Geronimo but I ran into a problem. As previously mentioned on
> this list, the idea for the extender was to call the Tomcat/Jetty
> ModuleBuilders with a bundle as an input and once the deployment
> process was done start the generated configuration. All without
> creating any additional temporary or permanent bundles.
> Because we don't have a single classloader that can load all the
> gbeans within the configuration, David Jencks added a special
> "classSource" attribute to GBeanData which can be used to figure out
> the right Bundle to load the gbean class. Now, since we use Java
> serialization to save and load gbeans, we actually need to set the
> right classloader when we deserialize the gbean. That is, during
> deserialization as soon as we read the "classSource" we need to lookup
> and set the right classloader and then read the rest of the gbean
> data. This should (and seems to) work when all the attributes of the
> gbean are accessible from the same classloader. But what about if the
> gbean has some attribute with some values from different classloaders?
> For example, the Map object we build for jndi context can contain
> objects from different classloaders. I'm not exactly sure what to do
> about it. Although maybe having a custom ObjectOutputStream with
> annotateClass() method that saves "classSource" type of info for each
> unique class might work. Ideas?
> Also, I'm dealing with lots of classloader issues since there is no
> single classloader that load all the gbean classes and module classes.
> A lot of Geronimo and other code assumes a single classloader and
> resolving these problems is time consuming and not very fun (although
> probably good in long term). So I'm wondering if we can still somehow
> assemble a single classloader in the extender. For example, the
> post shows a classloader that delegates a number of different bundles.
> Maybe we could use that in Geronimo especially since we can figure out
> the bundles needed from the configuration environment information.
There have been a number of situations while during the conversion that 
I've suspected we were going to need a classloader that could delegate 
to more than one bundle instance as we developed more complex dependency 
situations.  I suspect it's finally time to bit that particular bullet.

> Thoughts?
> Jarek

View raw message