geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: support for shared libraries/classes in Geronimo 1.1
Date Fri, 14 Apr 2006 15:20:49 GMT
Sorry, I should have described the function a little better.

There is one shared library gbean that will enhance the classpath with 
the jars from any number of shared libraries or shared class 
directories.   The gbean is a child of rmi-naming.  An application that 
wants to use the shared library would call out a dependency on the 
sharedlib config.

Joe


Aaron Mulder wrote:
> 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
> loader
> 
> 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?
> 
> Thanks,
>     Aaron
> 
> On 4/14/06, Joe Bohn <joe.bohn@earthlink.net> 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 earthlink.net
>>
>>"He is no fool who gives what he cannot keep, to gain what he cannot
>>lose."   -- Jim Elliot
>>
> 
> 
> 

-- 
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message