[
https://issues.redhat.com/browse/WFCORE-3307?page=com.atlassian.jira.plug...
]
James Perkins closed WFCORE-3307.
---------------------------------
Resolution: Rejected
The parameters passed to scripts, with very few exceptions, are not processed by the
script itself. They are passed to the main entry point and processed there after the JVM
has been started. With the example {{-Djboss.socket.binding.port-offset=100}} that is not
passed to the JVM in the {{JAVA_OPTS}}. That is passed to the entry point in the
{{org.jboss.as.standalone}} module.
Parameters passed to standalone.sh are not printed on startup
-------------------------------------------------------------
Key: WFCORE-3307
URL:
https://issues.redhat.com/browse/WFCORE-3307
Project: WildFly Core
Issue Type: Enhancement
Components: Scripts
Affects Versions: 3.0.3.Final, 8.0.0.Beta5
Environment: linux / windows
Reporter: jamie smith
Assignee: James Perkins
Priority: Minor
Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
Actually I think something like the output of `ps aux | grep
"org.jboss.as.standalone"` should also be printed, when jboss starts.
Not printing them causes confusion between what is printed and what is actually applied.
If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100`
and at the same time `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the
latter will be printed but the first will be used.
Someone might argue about setting only JAVA_OPTS before running standalone.sh.
The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh,
then the default Wildfly opts (-Djava.net.preferIPv4Stack=true"
-Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are
never used, which causes other problems. This could be a bug byitself, but for now I
consider it as expected behaviour.
So the most clean approach that I see for setting options in a single place (both with -D
and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a
wrapper script myapp-run.sh).
It should be possible however to be able to see them being printed somewhere.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)