Jens Deppe created GEODE-1331:
---------------------------------
Summary: gfsh.bat on Windows is incorrect
Key: GEODE-1331
URL: https://issues.apache.org/jira/browse/GEODE-1331
Project: Geode
Issue Type: Bug
Reporter: Jens Deppe
Initial report:
{quote}
I am doing testing in windows STS. I am not adding these dependencies jars,
gfsh.bat is what doing this.
C:\DEV\Pivotal\GemFire_v82014\bin\gfsh.bat has below code, which is setting
gemfire, antlr, gfsh-dependencies and pulse-dependencies jars in classpath.
Line 26 to 29
@set
GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
@if defined CLASSPATH (
@set GEMFIRE_JARS=%GEMFIRE_JARS%;%CLASSPATH%
)
C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
C:\DEV\Pivotal\GemFire_v82014\lib\antlr.jar
C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE
C:\DEV\Pivotal\GemFire_v82014\lib\pulse-dependencies.jar
Unix C:\DEV\Pivotal\GemFire_v82014\bin script, does not set these jars in
classpath.
Another observation is that, if I pass --include-system-classpath to gfsh start
server command, then it is prepending gemfire.jar and gfsh-dependencies.jar to
the system classpath and adding that to the server, that is what is shown in
logs
Class Path:
C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar
…………
………..
C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar
C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
start server \
--name=${NAME} --server-port=${PORT} \
--properties-file=${GEMFIRE_PWD}/resources/cache.properties \
--J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} \
--J=-Dgemfire.bind-address=${HOST_NAME}
--J=-Dgemfire.server-bind-address=${HOST_NAME} \
--J=-Dgemfire.locators=${HOST_NAME}[${LOCATOR_PORT}] \
--J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true \
--include-system-classpath
If I don’t pass this parameter, then it does not add gfsh-dependencies
Class Path:
C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
I am trying to do testing without using –include-system-classpath instead add
jars in to the start server –classpath as a work around.
{quote}
And a subsequent reply from John Blum:
{quote}
My apologies. I was not aware that you were launching your GemFire process
(e.g. Server) using Gfsh, and specifically with gfsh.bat on Windows.
I just confirmed the line(s) you were looking at in gfsh.bat, and indeed the
BAT file is wrong! Specifically, the classpath for the GemFire process is
being constructed from the following lines...
@set
GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
...
@set GFSH_JARS=;%GEMFIRE%\lib\gfsh-dependencies.jar
@set CLASSPATH=%GFSH_JARS%;%GEMFIRE_JARS%
The Windows BAT file is also inconsistent with the Bash shell version (gfsh),
which rightfully only contains...
GEMFIRE_JARS=$GEMFIRE/lib/gfsh-dependencies.jar
if [ "x$CLASSPATH" != "x" ]; then
GEMFIRE_JARS=$GEMFIRE_JARS:$CLASSPATH
fi
CLASSPATH=$GEMFIRE_JARS
In addition, the Bash shell version launches the Gfsh process using the java
-classpath option...
"$GF_JAVA" -Dgfsh=true
-Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
${JLINE_TERMINAL} -classpath "${CLASSPATH}" $JAVA_ARGS $LAUNCHER "$@"
Which does not "export", or rather, set the global System CLASSPATH environment
variable. Here it is only setting the Java System property to the Java
process, where as, I believe, the Window BAT file is actually setting the
System CLASSPATH environment variable, since there is no java -classpath option
present in the command to launch Gfsh...
@"%GF_JAVA%" -Dgfsh=true
-Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
%JAVA_ARGS% %LAUNCHER% %*
Regarding...
> I think we need Pivotal Engineering team to look into gfsh.bat and
> –include-system-classpath behavior.
Not exactly. --include-system-classpath basically functions such that it
appends the value of the System CLASSPATH environment variable to the forked
GemFire process launched from Gfsh if the user has set the global variable per
environment and wishes to use it.
In a nutshell, GemFire documentation use to erroneously recommend users to set
the System CLASSPATH environment variable. This is a serious JRE anti-pattern
that can adversely affect any and all running Java applications on the same
machine since all Java launcher invocations use the CLASSPATH environment
variable as part of the classpath on start, unlike the -classapth option, which
only pertains to that particular JVM instance invoked with the java launcher.
Therefore, -classpath should be preferred over setting the global, CLASSPATH
environment variable, which can lead to unintended consequences.
The --include-system-classpath was meant to restore the recommended behavior
and allow GemFire processes to use the global CLASSPATH environment variable in
their classpath, which just appends the value to the forked processes classpath
on start. I know, because I was also responsible for this, ;-)
See here \[1\] (notice the 'classpath' variable), then here \[2\], then here
\[3\], and then finally, here \[4\].
If you follow the logic closely, you will notice how it first adds the gemfire
JAR \[5\], then includes the user's classes \[6\] (as specified with the
--classpath option to start locator|server), next includes the global System
classpath \[7\] (as specified in the CLASSPATHenvironment variable), and
finally, includes any JAR files \[8\] (mainly from $GEMFIRE/lib, and
specifically/technically, only what was once the server-dependencies.jar \[9\]
file, now the geode-dependencies.jar in Apache Geode; NOTE: this is the Geode
codebase I am making references to).
Anyway, all of this is to say the --include-system-classpath is not going to
help and is not really what you want anyway. Essentially, you just want to
ensure that the application classes and JARs are on the classpath of the
GemFire process before the $GEMFIRE/lib/*-dependencies.jar files.
This is the problem your (local) test environment is currently having, which
was apparent in the classpath output of the server's log file on startup.
\[1\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1606-L1608
\[2\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1751-L1753
\[3\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1119-L1128
\[4\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1134-L1168
\[5\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1136
\[6\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1138-L1149
\[7\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1152-L1155
\[8\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1157-L1165
\[9\]
https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M2/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java#L1124
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
