geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell E Glaue (Commented) (JIRA)" <>
Subject [jira] [Commented] (GERONIMO-6275) Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir in shell scripts
Date Mon, 20 Feb 2012 05:57:34 GMT


Russell E Glaue commented on GERONIMO-6275:

The "# Resolve the full path to GERONIMO_SERVER" section is copied from the $PRG resolution
logic just a dozen lines prior in the section titled "# resolve links - $0 may be a softlink".

I have concern that putting path resolution code in a file identified/named for java environment
purposes (setjavaenv) could lead to confusion. Also, we would still be duplicating the "resolution"
code since it is identical to the existing duplicated code that resolves GERONIMO_HOME in
each of those same shell files (because I just copied it).

I hesitated in modifying existing code lines, so I went for the copy-and-paste. The ideal
resolution is probably to move the $PRG/$GERONIMO_HOME resolution code into a function.

RESOLVE_PATH=  # Global return variable for resolvePath()
resolvePath () {
  [ ! -d $LPRG ] && return 1
  while [ -h "$LPRG" ]; do
    ls=`ls -ld "$LPRG"`
    link=`expr "$ls" : '.*-> \(.*\)$'`
    if expr "$link" : '/.*' > /dev/null; then
      LPRG=`dirname "$LPRG"`/"$link"
  return 0

# resolve links - $0 may be a softlink
resolvePath "$0" && PRG="$RESOLVE_PATH"

# Get standard environment variables
PRGDIR=`dirname "$PRG"`

# Only set GERONIMO_HOME if not already set
[ -z "$GERONIMO_HOME" ] && GERONIMO_HOME=`cd "$PRGDIR/.." ; pwd`

# Set GERONIMO_SERVER if not already set, otherwise resolve the full path
if [ -z "$GERONIMO_SERVER" ] ; then
  resolvePath `cd "$GERONIMO_HOME"; cd $GERONIMO_SERVER 2>/dev/null && pwd` &&
found!" && exit 1

Unfortunately, bash functions cannot return strings, only an exit/return status in $?. So
we would have to use a global variable. Anyone have a more efficient idea for doing this?

> Defining and Using org.apache.geronimo.server.dir versus org.apache.geronimo.home.dir
in shell scripts
> ------------------------------------------------------------------------------------------------------
>                 Key: GERONIMO-6275
>                 URL:
>             Project: Geronimo
>          Issue Type: Sub-task
>      Security Level: public(Regular issues) 
>          Components: startup/shutdown
>    Affects Versions: 3.0-beta-1
>         Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4 (Tikanga);
Java JDK1.6.0_25
>            Reporter: Russell E Glaue
>            Assignee: Russell E Glaue
>            Priority: Minor
>              Labels: geronimo
>         Attachments: geronimo-6275-procrun_service.patch, geronimo-6275.patch
> Related: GERONIMO-6270, GERONIMO-6175, GERONIMO-6174, GERONIMO-5987, GERONIMO-4229
> It would be easier to support multiple server instances of Geronimo if there is one shell
variable that is used to reference the path on disk to the instance, proposed as GERONIMO_SERVER
as opposed to the GERONIMO_HOME installation path. This issue tracks the discussion and modification
of such a change.
> - GERONIMO_SERVER defaults to GERONIMO_HOME if no instances are specified
a relative path
> - GERONIMO_SERVER defines org.apache.geronimo.server.dir
> In the java code there are the following properties:
> # org.apache.geronimo.home.dir - equivelant to GERONIMO_HOME shell variable
> # org.apache.geronimo.server.dir - proposed to be equivelant to GERONIMO_SERVER 
> The words "BASE" versus "HOME" appear a few times in the source. Once example is "karaf.home"
and "karaf.base" properties. According to the code usage, it is aparant that these terms are
assumed to mean these things:
> # HOME - path location on disk of read-only binaries and configuration
> # BASE - path location on disk of read-write configuration and data storage
> The term BASE is intended to point at a Geronimo Server Instance Base path. However,
this has not been clearly defined, and has appeared to cause some misusage. Thus this and
other issues lead to the removal of GERONIMO_BASE shell variable and org.apache.geronimo.base.dir
java property in GERONIMO-4229 .
> Currently, to start a Geronimo Instance, the org.apache.geronimo.server.dir java property
must be defined in the GERONIMO_OPTS variable. However, this prevents the Shell scripts from
being able to know and use the path location to the Geronimo Server Instance.
> In particular, there are a few issues affected by a variable like this not being available.
> # Reported in GERONIMO-6174 - GERONIMO_TMPDIR is set in the shell/bat scripts as GERONIMO_HOME/var/tmp.
In turn, the java property "" is set to GERONIMO_TMPDIR (this is GERONIMO_HOME/var/tmp).
Shouldn't GERONIMO_TMPDIR instead be set to a value provided by GERONIMO_SERVER/var/tmp ?
> -- affected scripts: client, deploy, geronimo, internalLauncher, jaxws-tools
> -- This can be argued to whether or not all Geronimo Server Instance should share a common
temp directory.
> # Reported in GERONIMO-6174 - The java properties karaf.home and karaf.base are both
being set to GERONIMO_HOME. When instead karaf.base should be set to a value held by GERONIMO_SERVER.
> -- affected scripts: client, geronimo, internalLauncher
> -- see resulting errors and reasoning in GERONIMO-6174
> # Not Reported - The java property java.util.logging.config.file is being set to GERONIMO_HOME/etc/
. It is intended to be an empty configuration file. This only causes a problem when using
instances if GERONIMO_HOME/etc does not exist (it would not exist if GERONIMO_SERVER/etc is
intended to be used).
> -- affected scripts: client, geronimo, internalLauncher
> # Not Reported - Logging startup output to GERONIMO_HOME/var/log/geronimo.out - Obviously
if multiple instances are being started, this should be GERONIMO_SERVER/var/log/geronimo.out
. Any error is silent if var/log/geronimo.out does not exist.
> -- affected scripts: geronimo
> # Not Reported - The register-service script does a grep and awk on GERONIMO_HOME/var/config/
to discover the portOffset . Obviously this will not work for multiple instances
> -- The register-service script does not take multiple instances into consideration at
> -- affected scripts: register-service
> Solution:
> - Create a new shell variable GERONIMO_SERVER to hold the path location to the run-time
server configuration, and leave GERONIMO_HOME to hold the path location to the Geronimo Installation
> Arguments:
> - If GERONIMO_SERVER defaults to GERONIMO_HOME, then any installation not having multiple
instances configured will not be affected.
> - This will not resolve the multiple instance support issue in Geronimo, GERONIMO-6270,
but having this support in the shell scripts will get Geronimo much closer.
> - About half of the currently known issues (listed above) can be resolved with the addition
of GERONIMO_SERVER as proposed.
> The remaining currently known issues will be:
> # GERONIMO-6174: the proper use of karaf.home versus karaf.base
> # GERONIMO-6270 SnapshotConfigXMLBuilder using the org.apache.geronimo.server.dir/var
> # GERONIMO-5987 and GERONIMO-6270: ActiveMQ using org.apache.geronimo.server.dir as the
base for var rather than the current working directory the run-time server is in at startup
> # GERONIMO-6175: The Geronimo Repository using org.apache.geronimo.server.dir instead
of org.apache.geronimo.home.dir

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message