[
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 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}
was:
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}
> 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 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}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
