geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Updating a GBean's classloader
Date Wed, 01 Mar 2006 16:59:00 GMT

On Mar 1, 2006, at 8:34 AM, A. Zeneski wrote:

> David,
> This could work if I am able to build this configuration  
> classloader myself and make it available to the web applications.  
> However, I was thinking, is it possible to build a custom  
> repository loader which (after loading the default repository)

the repository is not "loaded", or I don't understand your wording.   
The repository is where you put stuff so it can be consistently  
referenced by configuration classloaders.  Nothing gets into a  
classloader without being in the dependency list of a configuration  
(or, I should perhaps say, the transitive closure of a  
configurations' dependencies).

> will invoke allowing me to load all our "components" and the  
> libraries/resource for each. This would then be the parent  
> classloader to everything running below.
> I haven't dug into the repository code yet to see if this is  
> possible; I expect the repository loader is just a gbean which  
> maybe I can extend or add something after it runs.

well, its software, so with sufficient work you can make it do pretty  
much whatever you want.  I really don't understand what you are  
trying to do though.  We now (in 1.1) have 2 ways for you to  get  
your jars/classes into a parent classloader for other components/ 
applications to use:
- put them in the geronimo repo, so you can manage them in a fully  
versioned manner with the help of maven style tools
- put them in a j2ee app where you can access them using the  
primitive j2ee tools and ignore versioning, provenance, and all other  

You could write a config builder to construct a configuration with  
URLs to wherever you want, but I'm having a hard time seeing the  
value.  I think you would also need to write a ConfigurationStore  
that would be where this configuration was deployed, but I don't  
understand what you want to do well enough to be very confident on  
that point.  Can you explain why neither of the methods we already  
support will work for you?

david jencks

> Andy
> On Feb 28, 2006, at 4:00 PM, David Jencks wrote:
>> On Feb 28, 2006, at 12:39 PM, A. Zeneski wrote:
>>> I am attempting to implement a GBean to start up the Open For  
>>> Business suite of applications. Due to large number of libraries  
>>> involved we have some tricky ways of loading the application  
>>> today. Currently we have a small kernel which starts up (much  
>>> like Geronimo) and dynamically loads all the classes and builds a  
>>> initial classloader.
>>> From there, using this newly created classloader we startup the  
>>> server components, i.e. JOTM, Tomcat, etc. We are looking to move  
>>> away from this approach and instead of embedding these components  
>>> inside the application, we prefer to run the application inside a  
>>> container. Specifically Geronimo. Now that OFBiz has been  
>>> accepted into the Apache Incubator; I am motivated to get this  
>>> done ASAP.
>>> What I have attempted to do first was just replace the context  
>>> classload on the current thread of the GBean and used a quick  
>>> JSR88 implementation to deploy the web applications using this  
>>> GBean as the parent. However, the classloader obtained (after  
>>> looking at the GBean source code) is cached on the object itself  
>>> and appears to be immutable.
>>> My second attempt was based on code I found in the Kernel API.  
>>> After creating my classloader, I defined a new GBean (from inside  
>>> the initial GBean which does the classloading). I first grab an  
>>> instance of the Kernel:
>>> Kernel kernel = KernelRegistry.getSingleKernel();
>>> Then I attempt to:
>>> ObjectName ofb = JMXUtil.getObjectName(":role=OFBizCore");
>>> GBeanData ofbBean = new GBeanData(ofb, OFBLoader.GBEAN_INFO);
>>> kernel.loadGBean(ofbBean, cl);
>>> kernel.startGBean(ofb);
>>> Passing it the classloader *I* created (cl). I was hoping then  
>>> that if I configured the web applications to have the parent  
>>> ':role=OFBizCore' in their geronimo-web.xml configuration this  
>>> would set their servlet context classloader would be a child of  
>>> the classloader I created (loading the huge amount of classes/ 
>>> libraries required).
>>> However, this bean (ofbBean) remains in the STARTING status and  
>>> never appears to start.
>> even if you get it to start I don't think this is likely to work  
>> well.
>>> Can anyone suggest to me a way to accomplish my goal.
>>> 1) Load all our classes in a dynamic way. I do not wish to copy  
>>> all libraries and configuration files into the standard Geronimo  
>>> repository.
>> I have to ask, why not put all the jars into the geronimo repo?  I  
>> think you will find that it really simplifies managing the  
>> dependencies.  however....
>>> 2) Load our web applications from their current location using  
>>> the classloader from #1. Our web applications are not in a single  
>>> location and are all expanded.
>> I think you need one of the features just implemented in the  
>> highly unstable 1.1 branch.  As of this morning, a web app uses a  
>> configuration classloader.  In particular, this means that the  
>> configuration classloader for a war includes all the jars from WEB- 
>> INF/lib and the WEB-INF/classes directory.  A consequence of this  
>> is that if you include the war configuration as a parent of some  
>> other configuration, the classes from the WEB-INF stuff will be  
>> available to the child configuration.  IIUC this is what you want.
>> If this is not what you need, please explain further.
>> While AFAIK the 1.1 branch works fine as of this morning, it is  
>> undergoing extensive rapid change and you shouldn't expect it to  
>> work at any particular moment for the next couple of weeks.
>> hope this helps
>> david jencks
>>> I am open to suggestions.
>>> Andy

View raw message