[
https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin....
]
Ondrej Zizka commented on WFLY-2427:
------------------------------------
JBDS stores the JVM arguments for various containers here:
https://github.com/jbosstools/jbosstools-server/tree/master/as/plugins/or...
My Suggestion is to move this responsibility to devs/productization and QA of the
respective products, and allow them to adjust the JVM arguments using a static file
(.properties perhaps) which could override the defaults provided by the Launcher.
Launcher API
------------
Key: WFLY-2427
URL:
https://issues.jboss.org/browse/WFLY-2427
Project: WildFly
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Server
Reporter: Brian Stansberry
Assignee: Rob Stryker
1) The AS should have some sort of API for launching our processes so tools that want a
process have a clear contract instead of having to guess at what's relevant in our
ever-changing scripts.
2) We want the main class in our process launch to be what's invoked by java -jar
jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff
and then calls org.jboss.modules.Main.
3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant
to an AS launcher API, because many of those things are not relevant to JBoss Modules in a
generic sense.
What we could do though is provide a launcher lib that isn't involved at all in our
normal boot. Something that would only be used by tools that want to launch a separate,
i.e. non-embedded, AS process.
So, some sort of stable configuration API and then a simple
java.lang.Process launch()
Basically, a utility that does the ProcessBuilder stuff that everybody is doing
themselves now.
h2. HOWEVER...
Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above
launch() method.
So, besides that launch method, look into adding some methods to give the necessary
inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the
process but can still get a standard launch configuration.
I'd only want to do that if those methods would return something generally
understandable, but a String or List<String> for classpath, List<String>s for
vm/program args, some representation that "-jar jboss-modules.jar" is the way to
get the main class -- those all seem generic enough.
Any "which VM" stuff is consider out of scope; choosing the VM is the
responsibility of the tool. Options that are not universally supported across VMs and are
those a function of VM choice, like whether to use -server, are also out of scope.
h2. Example of EAP 6.0 launch:
VM arguments:
-server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true
-Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman
-Djava.awt.headless=true
"-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log"
"-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties"
"-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
Program argument:
-mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule
javax.xml.jaxp-provider org.jboss.as.standalone -b localhost
--server-config=standalone.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira