geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: support for shared libraries/classes in Geronimo 1.1
Date Fri, 14 Apr 2006 14:47:54 GMT
I'm not really following your description of how this will work, but
this is my thought:

 - We pick a shared library directory (var/shared/lib is fine with me)
and make that the standard.  I don't think shared classes are even
necessary, though I don't object to having a directory for that too.

 - If the directory is not present during startup, we create it

 - By default, application deployments do not see shared libraries

 - If you put an <enable-shared-libs /> in the <environment> in your
plan, then the shared libraries are added to the application class

I'm imaging there's one "shared library GBean" in the whole server and
you set the directory on that in the j2ee-server plan and we don't
encourage people to change it (though they could in config.xml I
suppose).  Is that what you have or are you thinking of one GBean per
application deployment?


On 4/14/06, Joe Bohn <> wrote:
> Dain added some initial support for shared libraries in 1.1 and (with
> the help of David Jencks) I have a configuration and gbean to make the
> feature available to applications to use.  I'll create a patch for this
> today for Geronimo 1.1.
> However, I have a question about how "public" we want this function to
> be.  There has been some concern that we shouldn't encourage the use of
> shared libraries.  The thought is that it is better to use the
> repository and explicit dependencies.
> If we include the gbean in the configuration for an assembly then the
> any specified shared library(ies) or class directory(ies) must exist or
> an exception is thrown.  At the moment I'm using var/shared/lib and
> var/shared/classes as the defaults.
> If we just add the gbean to the assemblies without the default libraries
> then the user will have to update the configuration to use the feature
> and specify the attributes for the libs or classes.  That isn't very
> user friendly and doesn't provide a "default" location.  On the other
> hand, adding in defaults requires that we also add in the empty
> directories which is a bit of an advertisement to use them.
> At the moment, I'm leaning toward adding the default directories.  Any
> recommendations before I create the patch?
> Joe
> --
> Joe Bohn
> joe.bohn at
> "He is no fool who gives what he cannot keep, to gain what he cannot
> lose."   -- Jim Elliot

View raw message