It is my doing that killed the org.apache.geronimo.base.dir java property and GERONIMO_BASE shell variable back in
GERONIMO-4229 . We should not resurrect them, but the idea of GERONIMO_BASE should be brought back from the dead. We need to have a complete path reference to the running Geronimo instance of interest. Then we make sure we consistantly use it, and document its intentional meaning.
We now have these three run-time path properties in Geronimo
3. org.apache.geronimo.server.dir (which can be "org.apache.geronimo.home.dir/org.apache.geronimo.server.name", but can also be a complete path to some directory outside the Geronimo install base)
Currently, the property org.apache.geronimo.server.dir essentially is the "base" directory of the Named Server Instance. If a user supplies the property org.apache.geronimo.server.name, then the value for the property org.apache.geronimo.server.dir is generated from it relative to org.apache.geronimo.home.dir .
To help developers more easily keep things separated in the head, I recommend we follow two policies. One for shell coding, and one for java coding. I suggest a new variable 'GERONIMO_SERVER' to hold the full path to the named server instance.
1. In shell code, ALWAYS use the GERONIMO_SERVER variable for run-time configuration files and read-write data that is created or modified during run-time (This includes the Geronimo repository). Only use GERONIMO_HOME to reference binary code, or any static data that is expected to be read-only (not supposed to be modified).
2. In Java code, ALWAYS use the org.apache.geronimo.server.dir property for run-time configuration files and read-write data that is created or modified during run-time (This includes the Geronimo repository). Only use org.apache.geronimo.home.dir to reference binary code, or any data that is expected to be read-only.
- GERONIMO_SERVER can be initialized by the user as a relative path, or a full path. If the path is relative, then the shell code should expand it by prepending the value of GERONIMO_HOME .
- org.apache.geronimo.server.dir is the same as GERONIMO_SERVER. If it does not reference a full path, the java code will expand it by prepending the value of org.apache.geronimo.home.dir .
- If we treat org.apache.geronimo.server.dir as descibed previously, we no longer need org.apache.geronimo.server.name . However, since there is no harm or confusion at this time, we should keep it for now and treat it as a relative path to the geronimo server instance from org.apache.geronimo.home.dir, but only if org.apache.geronimo.server.dir is not defined. So org.apache.geronimo.server.dir would have precedence over org.apache.geronimo.server.name .
We should make a standardization like this, and preach it in the developer documentation (perhaps page 1). For the last 5 years I have been involved in Geronimo, it seems like this detail gets overlooked from time to time. I don't pass blame though, it has been confusing on what the proper usage is. But we should start by stamping out the confusion.
Also we should outline what we intend by "home" versus "base"
When karaf was added to Geronimo, we got two new java properties: karaf.home and karaf.base . It is already not being used consistently as intended. As described in
GERONIMO-6174, Karaf is written to look for
/etc/shell.init.script each time a shell session is started. When instead it should look for
/etc/shell.init.script . (See: geronimo/server/trunk/framework/configs/karaf-framework/src/main/distribution/text/etc/system.properties).
From what I read/interpret from the karaf code, "base" is intended to be the path to the named server instance.