You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/04/14 16:07:01 UTC
support for shared libraries/classes in Geronimo 1.1
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
Re: support for shared libraries/classes in Geronimo 1.1
Posted by Joe Bohn <jo...@earthlink.net>.
Some additional information in the description below
Joe Bohn wrote:
> 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.
It updates the classloader by appending the sharedlibs to the
multiparentclassloader (the new sharedlib class and the interaction with
the multiparentclassloader is what Dain had already created).
> 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 <jo...@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
Re: support for shared libraries/classes in Geronimo 1.1
Posted by Joe Bohn <jo...@earthlink.net>.
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 <jo...@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
Re: support for shared libraries/classes in Geronimo 1.1
Posted by Wade Chandler <hw...@yahoo.com>.
--- John Sisson <jr...@gmail.com> wrote:
> 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.
> >
> A shared classes directory may be useful for things
> such as property
> files that people may want to be able to easily edit
> without needing to
> jar it up.
>
> John
That's what WEB-INF/classes is for.
Wade
Re: support for shared libraries/classes in Geronimo 1.1
Posted by John Sisson <jr...@gmail.com>.
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.
>
A shared classes directory may be useful for things such as property
files that people may want to be able to easily edit without needing to
jar it up.
John
> - 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 <jo...@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
>>
>>
>
>
Re: support for shared libraries/classes in Geronimo 1.1
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <jo...@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
>