]
Tomaz Cerar closed WFCORE-643.
------------------------------
Fix Version/s: 2.2.0.Final
Resolution: Out of Date
On Windows, setting the JAVA_OPTS variable is not
-------------------------------------------------
Key: WFCORE-643
URL:
https://issues.jboss.org/browse/WFCORE-643
Project: WildFly Core
Issue Type: Bug
Components: Scripts
Affects Versions: 1.0.0.Beta4
Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64.
Hardware specs:
CPU: Intel Core i7-3720QM CPU @ 2.60 GHz
RAM: 16.0 GB
GPU: NVIDIA Quadro K1000M
Others upon request.
Reporter: Tom Kelley
Priority: Minor
Fix For: 2.2.0.Final
{warn} This issue was copy/pasted from a github issue
[
here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue
duplication, 2) the length of the issue, 3) any poor communication that the transcription
caused. {warn}
My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I
wrote a small script that lives in the bin directory and looks something like this:
{code}
@rem Delete current log file
del /F /Q ..\standalone\log\server.log
@rem Set Java Opts because I want to
set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops
-Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M
-Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n"
@rem Set the new Java Home
set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre
@rem Run Jboss
standalone.bat -c=standalone-full.xml --debug
{code}
I noticed when I was starting the server that the JAVA_OPTS in the debug text were not
what I was passing in. I figured I could get to the bottom of what was going on, so I
started digging in. My investigation led me to standalone.conf.bat, which looks like
this:
{code}
rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
rem set PRESERVE_JAVA_OPTS=true
if not "x%JAVA_OPTS%" == "x" (
echo "JAVA_OPTS already set in environment; overriding default settings with
values: %JAVA_OPTS%"
goto JAVA_OPTS_SET
)
{code}
This is very interesting. This snippet of code appears to be a bug. As someone who has
worked with batch files, I believe that the correct code should look like this:
{code}
rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
rem set PRESERVE_JAVA_OPTS=true
if not "x"%JAVA_OPTS% == "x" (
echo "JAVA_OPTS already set in environment; overriding default settings with
values: %JAVA_OPTS%"
goto JAVA_OPTS_SET
)
{code}
You must be thinking, "if you know how to do this, why don't you just make the
change yourself? It seems trivial." I would, but I'm not able to find the batch
file in the source tree. It appears (to me) that the batch file is generated, and I
don't know what to start looking for in order to fix this issue on my own.
As such, I've created a test batch file (meant to be run on Windows) that I've
attached to this Issue. When the issue is fixed, it should output something like this:
{code}
Calling
"C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat"
"JAVA_OPTS already set in environment; overriding default settings with values:
"Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java"
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME:
"C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT"
JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java"
JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the
JAVA_OPTS now.""
===============================================================================
Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now.
{code}
The batch file can be acquired
[
here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-...],
just save the link as a batch file, or save it and change the extension (the same way that
we get around email filters that don't let us send *.exe's). The way that I ran
this was to put the batch file at the root of the Wildfly directory and then call it using
window's CMD. The test case does several things:
1. Maven clean
2. Call build.bat
3. Set a JAVA_OPTS system variable
4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as
long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT).
I would love to take lead on fixing this, but I'm not sure where to start. If someone
could give me a point in the right direction, that would be great. Thanks.