[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-1331:
------------------------------
Description:
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}
was:
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 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
{noformat}
> 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:
> {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)
