[jboss-jira] [JBoss JIRA] (WFLY-4523) On Windows, setting the JAVA_OPTS variable is not

On Windows, setting the JAVA_OPTS variable is not ------------------------------------------------- Key: WFLY-4523 URL: https://issues.jboss.org/browse/WFLY-4523 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 9.0.0.Alpha1 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 Assignee: Alexey Loubyansky Priority: Minor {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.