geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Zeneski" <>
Subject Re: Updating a GBean's classloader
Date Wed, 01 Mar 2006 16:34:08 GMT

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) 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.


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