geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Why is GERONIMO_HOME not passed into the server?
Date Sat, 27 Jan 2007 22:38:51 GMT
I think in order to allow multiple instances to work off of the same  
installation effectively we need to have a tiered repository support,  
so that each instance could include a shared read-only repository  
(the system repository), and then a read-write repository (instance  
repository), where artifact resolution would first check the instance  
repo, then the system repo.

If we do want to start supporting this, I suggest we also revisit the  
basic server's file structure, as we will need to insert a hierarchy  
for the instance data.


On Jan 27, 2007, at 1:51 PM, Matt Hogstrom wrote:

> 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  
> installation.
> 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:
> ./repository
> ./lib
> ./var/log
>         config
>         activemq
>         howl
> 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  
> in the GERONIMO_INSTANCE tree.
> 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.
> Thoughts?
> Matt
> 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  
>> 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  
>> 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