geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Why is GERONIMO_HOME not passed into the server?
Date Sat, 27 Jan 2007 21:51:41 GMT
I've been looking at this recently interms of being able to run  
multiple oag instances out of the same filesystem.  This means we  
need to identify several different points in the filesystem.  This is  
not exhaustive but really for discussion since Ted brought it up.

One is the location of the Geronimo server.  I'll refer to this as  
$GERONIMO_HOME.  This directory is the root of the Geronimo  

The next Location is the $GERONIMO_INSTANCE which would contain the  
parts of the repository that an individual instance would need.  This  
would include a repository, var entries for config, logs, etc.  One  
approach would be to make the GERONIMO_INSTANCE be a shadow of the  
normal dir structure for GERONIMO_HOME that is only populated with  
items that are different from the base install.  I think this would  
include things like:


The above is not exhaustive but for discussion.  It would be useful  
for multiple server instances to have their own repository for  
installing applications so that individual instances would be  
seperate and could actually be managed with different OS userid  
authentication.  If GERONIMO_HOME was not the same as  
GERONIMO_INSTANCE then the dir tree for instance would be searched  
first and if a file wasn't found then we could then look in  
GERONIMO_HOME.  Write access would always (as far as I can tell) be  

I'm not sure how deeply we need to flush this out but at a high level  
I think we should rev the kernel to support the above for 2.0 so we  
don't have to modify the way it operates down the road.



On Jan 27, 2007, at 9:39 AM, Ted Kirby wrote:

> Thanks Jacek.  That is a good suggestion.  Here is what I have come up
> with in thinking about a patch:
> The server java code has two directory notions: base, used with
> ServerInfo.resolve(), and baseServer, used with
> ServerInfo.resolveServer(). Base can be set with the oag.home.dir
> system property, and baseServer can be set with the oag.server.dir and
> system properties (where oag is short for
> org.apache.geronimo).
> The geronimo script uses GERONIMO_HOME for the bin directory, and
> GERONIMO_BASE for the lib and var directories.  If GERONIMO_BASE is
> not set, it will set it to GERONIMO_HOME.  Finally, on java
> invocation, it sets the system property oag.base.dir to GERONIMO_BASE.
> The java code does not read this system property!
> I thus have two recommendations:
> The quick and conservative one is to have the geronimo script set
> oag.home.dir to GERONIMO_BASE, instead of setting oag.base.dir.
> The more complex and radical recommendation is to remove GERONIMO_BASE
> from the geronimo script, replacing it with GERONIMO_HOME.
> Thanks,
> Ted
> On 1/26/07, Jacek Laskowski <> wrote:
>> On 1/26/07, Ted Kirby <> wrote:
>> > Providing the org.apache.geronimo.home.dir system property to allow
>> > the home directory to be passed in is good, but if this is not used
>> > (and I'd don't feel it should be required/used in the normal case),
>> > DirectoryUtils.getGeronimoInstallDirectory() is used to  
>> determine the
>> > home directory.  This method uses machinations that do not resolve
>> > correctly if the home directory is a symbolic link.  Since the
>> > invoking geronimo script sets and uses GERONIMO_HOME, why does  
>> it not
>> > pass this value into the server?  I would think that  
>> BasicServerInfo
>> > would want to set baseDirectory to GERONIMO_HOME (if the
>> > org.apache.geronimo.home.dir system property is not set), and  
>> invoke
>> > DirectoryUtils.getGeronimoInstallDirectory() only if  
>> > not set.
>> I think you might want to provide a patch that someone will review  
>> and
>> commit. What do you think? if it doesn't break the tests it's a good
>> start.
>> Jacek
>> --
>> Jacek Laskowski

View raw message