Updating a GBean's classloader

["A. Zeneski" <ja...@ofbiz.org>]

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.

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.

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 am open to suggestions.

Andy

Re: Updating a GBean's classloader

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

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

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?

thanks
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
>>>
>>
>

Re: Updating a GBean's classloader

["A. Zeneski" <ja...@ofbiz.org>]

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

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

Re: Updating a GBean's classloader

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

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
>