[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Markito Oliveira updated GEODE-1331:
--------------------------------------------
Sprint: 1.0.0-incubating.M3
> 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
> Fix For: 1.0.0-incubating.M3
>
>
> 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)
