geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: shared libraries in the OAS way
Date Mon, 13 Oct 2008 18:39:26 GMT

On Oct 13, 2008, at 10:56 AM, Juan David wrote:

> Hi David
> I think that solution is what I needs.
> Are there any examples in how to implement and deploy the classloader
> plugins and of course define dependencies among them

First of all you should be using geronimo 2.1.x or if you are really  
daring 2.2-SNAPSHOT, plugins don't work all that well before 2.1.

Second you should use maven as it is by far the simplest way to  
construct plugins, especially in a reproducible way.

The most prominent examples in 2.1 of "classloader" plugins are the  
jee-specs and xmlbeans configs under framework/configs.

The way you can tell it's a "classloader" plugin is that there are no  
gbeans specified in the plan:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="">


The pom should list the plugin parents (parent classloaders) and jars  
you need in your classloader as maven dependencies.  The packaging  
should be:


You need to list the geronimo-gbean-deployer as a "provided"  
dependency so the car-maven-plugin can find it:


and finally you need the c-m-p configuration:


Related to your other question related to executing some code before  
your apps start, you might be able to include the service gbean you  
need in one of these plugins.

hope this helps, please ask if you need more hints

david jencks

> Thank you very much
> Juan David Perez
> djencks wrote:
>> On Oct 13, 2008, at 9:51 AM, Juan David wrote:
>>> Hi All
>>> I would like to know how to accomplish shared libraries in the OAS
>>> way on
>>> Geronimo.
>>> What I mean by OAS way is the possibility to define a shared library
>>> that
>>> holds some jars and also can define dependencies with some other
>>> libraries.
>>> It is also possible to define a default set of dependencies for the
>>> applications (by adding a dependency to the default application), so
>>> every
>>> application deployed will have a set of dependent jars by default.  
>>> The
>>> application can remove any dependency on the deployment plan and the
>>> administrator can change de dependency for all application without
>>> the need
>>> to have new deployments plans for every application and redeploy.
>> While sharedlib might give you a quick solution it won't help track
>> what depends on what.  I'd be leery of having classpath changes not
>> reflected in the deployed artifacts.
>> You can define "classloader" plugins that simply have a list of
>> dependencies and no services.  These dependencies can be jars or  
>> other
>> plugins: the classloaders (and plugins) form a directed acyclic
>> graph.  Your app can depend on one of these "classloader" plugins and
>> get this classloader as a parent.
>> I'd recommend changing the version on such a plugin every time you
>> change the contents and using artifact-aliases and the "obsoletes"
>> element to have each new version replace its predecessors.  This will
>> give you fairly transparent auditing of exactly what jars your apps
>> are using.
>> thanks
>> david jencks
>>> Thanks in advance
>>> JuanDa
>>> -- 
>>> View this message in context:
>>> Sent from the Apache Geronimo - Users mailing list archive at
> -- 
> View this message in context:
> Sent from the Apache Geronimo - Users mailing list archive at  

View raw message