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 <[EMAIL PROTECTED]> 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
