geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Deppe (JIRA)" <>
Subject [jira] [Created] (GEODE-1331) gfsh.bat on Windows is incorrect
Date Mon, 02 May 2016 17:12:12 GMT
Jens Deppe created GEODE-1331:

             Summary: gfsh.bat on Windows is incorrect
                 Key: GEODE-1331
             Project: Geode
          Issue Type: Bug
            Reporter: Jens Deppe

Initial report:
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 (



C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE


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:\Program Files\Java\jdk1.7.0_67\lib\tools.jar



start server \

--name=${NAME} --server-port=${PORT} \

--properties-file=${GEMFIRE_PWD}/resources/ \

--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 \



If I don’t pass this parameter, then it does not add gfsh-dependencies

  Class Path:




I am trying to do testing without using –include-system-classpath instead add jars in to
the start server –classpath as a work around.

And a subsequent reply from John Blum:
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

@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

The Windows BAT file is also inconsistent with the Bash shell version (gfsh), which rightfully
only contains...

if [ "x$CLASSPATH" != "x" ]; then


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

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


> I think we need Pivotal Engineering team to look into gfsh.bat and –include-system-classpath

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

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.


This message was sent by Atlassian JIRA

View raw message