geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-1331) gfsh.bat on Windows is incorrect
Date Tue, 07 Jun 2016 21:53:21 GMT


ASF subversion and git services commented on GEODE-1331:

Commit 8e21638ce336aee07bec33d140500c76d1cedc53 in incubator-geode's branch refs/heads/feature/GEODE-837
from [~kduling]
[;h=8e21638 ]

GEODE-1331: gfsh.bat on Windows is incorrect.

* Renamed internal variable from CLASSPATH to DEPENDENCIES.
* Verified @setlocal was not altering the System environment variables for the shell.
* Launch with -classpath param like the bash script does.
* Ensured command-line arguments match bash script's order of arguments.
* This closes #149

> gfsh.bat on Windows is incorrect
> --------------------------------
>                 Key: GEODE-1331
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: gfsh
>            Reporter: Jens Deppe
>            Assignee: Kevin Duling
>             Fix For: 1.0.0-incubating.M3
> Initial report:
> {noformat}
> 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\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/ \
> --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.
> {noformat}
> And a subsequent reply from John Blum:
> {noformat}
> 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
> 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
> fi
> In addition, the Bash shell version launches the Gfsh process using the java -classpath
> "$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
> Regarding...
> > 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 CLASSPATH
> environment 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; 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]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> [8]
> [9]
> {noformat}

This message was sent by Atlassian JIRA

View raw message