Changing the classloader in Geronimo

[Martin Sparenberg <ma...@googlemail.com>]

Hi,

this is probably an uncommon problem, but maybe someone encountered a
similar situation and knows a solution:  :)

We have a build environment with a heavy amount of jar files that are too
much to copy for test-runs into the app structure (WEB-INF/...). (ok, this
is also very inhouse-special, never mind ;) )
When using a plain tomcat environment in the past we take a customized
classloader that knows the special locations of the libs and puts the fs
paths of them to the classpath.
Now we want to switch to geronimo (as the application is to be more
jee-ified).
I found several options for configuring geronimo's classloader but up to now
I found no way for replacing it by an own extension. :(
In tomcat I can name an own loader in WEB-INF/ROOT.xml as <Loader
className="..."/> but that didn't work in Geronimo (or is it just another
file?).
I "played around a bit" with the gbean settings in the geronimo-web.xml but
without success.

Is there a way for replacing/extending the classloader used for my
application in Geronimo?
Or (ever better) is there a way to get to my jars on their team environment
places in the filesystem just by configuration? As I understand, the
'dependency' tags in geronimo-web.xml refers "only" to the libs in the
servers's repository.

Thank you in advance,

Martin

Re: Changing the classloader in Geronimo

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

On Apr 15, 2009, at 8:47 AM, Martin Sparenberg wrote:

> Hi,
>
> this is probably an uncommon problem, but maybe someone encountered  
> a similar situation and knows a solution:  :)
>
> We have a build environment with a heavy amount of jar files that  
> are too much to copy for test-runs into the app structure (WEB- 
> INF/...). (ok, this is also very inhouse-special, never mind ;) )
> When using a plain tomcat environment in the past we take a  
> customized classloader that knows the special locations of the libs  
> and puts the fs paths of them to the classpath.
> Now we want to switch to geronimo (as the application is to be more  
> jee-ified).
> I found several options for configuring geronimo's classloader but  
> up to now I found no way for replacing it by an own extension. :(
> In tomcat I can name an own loader in WEB-INF/ROOT.xml as <Loader  
> className="..."/> but that didn't work in Geronimo (or is it just  
> another file?).
> I "played around a bit" with the gbean settings in the geronimo- 
> web.xml but without success.
>
> Is there a way for replacing/extending the classloader used for my  
> application in Geronimo?
> Or (ever better) is there a way to get to my jars on their team  
> environment places in the filesystem just by configuration? As I  
> understand, the 'dependency' tags in geronimo-web.xml refers "only"  
> to the libs in the servers's repository.

There are a lot of choices.  Which one you choose may depend on your  
goals for your build system.

There are three classes of solution:

1.  Get the jars into the appropriate places in the geronimo  
repository and reference them as dependencies in your geronimo-web.xml  
environment element.  This is easiest if you like maven.  In this case  
the jars will all be in the application classloader.
-a. assemble a custom server including the jars
-b use a gshell script to install the jars into an existing geronimo  
server
-c build your application as a geronimo plugin: installing it in a  
geronimo server will pull in all the dependencies  from a suitable  
maven repo.  If the jars are already there, just your app will be  
installed
-d A final possibility for this approach is to assemble a custom  
server around your applicatiion deployed as a geronimo plugin: this  
gives you an easy to distribute complete server including your app.

2. use the shared-lib in geronimo: put all the jars in the shared lib  
directory.  You can alter what this directory is if you don't like the  
default location.  In this case the jars will all be in a parent   
classloader to the application classloader.  I consider this a nasty  
hack but a lot of people find this useful.

3. deploy your application in-place exploded.  In this case you'll  
only be changing bits of code and redeploying, the jars will  
presumably stay unchanged in the WEB-INF/lib directory in your  
exploded war.

I greatly prefer all the options under (1).

thanks
david jencks

>
>
> Thank you in advance,
>
> Martin