[ 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)