[ https://jira.jboss.org/browse/JBAS-8063?page=com.atlassian.jira.plugin.sy... ] Andrew Dinn updated JBAS-8063: ------------------------------ Description: run.sh executes "$JAVA" -version at various places. The version in trunk does so at line 184 in order to check whether this is a 64 bit JVM. Unfortunately it actually executes "$JAVA" $JAVA_OPTS -version This works if the caller of run.sh has not set JAVA_OPTS in which case it will only contain settings added by the run.sh script itself. However, it is no use when JAVA_OPTS contains settings like -javaagent:<agentlib> etc since this can stop the java -version call from exiting. I do't think there is any need to pass JAVA_OPTS here (none of the other cases where java -version is executed need to do so). If it really is necessary to pass some of the values added by run.sh to java at thsi point then this should be done by accumulating the addde values up to this point without including the values supplied by the caller of run.sh. Assigning this to Mladen as his fingerprints are on the offending line :-) was: run.sh executes "$JAVA" -version at various places. The version in trunk does so at line 184 in order to check whether this is a 64 bit JVM. Unfortunately it actually executes "$JAVA" $JAVA_OPTS -version This works if the caller of run.sh has not set JAVA_OPTS in which case it will only contain settings added by the run.sh script itself. However, it is no use when JAVA_OPTS contains settings like -javaagent:<agentlib> etc since this can stop the java -version call from exiting. I do't think there is any need to set JAVA_OPTS here (none of the other cases where java -version is executed need to do so). If it really is necessary to pass some of the values added by run.sh to java at thsi point then this should be done by accumulating the addde values up to this point without including the values supplied by the caller of run.sh. Assigning this to Mladen as his fingerprints are on the offending line :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8063?page=com.atlassian.jira.plugin.sy... ] Mladen Turk commented on JBAS-8063: ----------------------------------- It's not as simple as removing JAVA_OPTS when testing the version. On JVM's that allow dual architecture mode supplying -d64 or -d32 in the JAVA_OPTS will at the end determine the actual architecture used. Omitting JAVA_OPTS in those situations would give the wrong results. I suppose we should search the JAVA_OPTS for this modifiers and call the java -version with those params only. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8063?page=com.atlassian.jira.plugin.sy... ] Mladen Turk resolved JBAS-8063. ------------------------------- Resolution: Done Fixed in the trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira