[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling reassigned GEODE-1331:
-----------------------------------
Assignee: Kevin Duling
> gfsh.bat on Windows is incorrect
> --------------------------------
>
> Key: GEODE-1331
> URL: https://issues.apache.org/jira/browse/GEODE-1331
> 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 (
> @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.
> {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
> @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 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]
> 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
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
