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.
--jason
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
oag.server.name 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 <[EMAIL PROTECTED]> wrote:
On 1/26/07, Ted Kirby <[EMAIL PROTECTED]> 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
GERONIMO_HOME is
> 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
http://www.JacekLaskowski.pl
