[JBoss AS 7 Development] - Using the CLI remote client jar
by Stan Silvert
Stan Silvert [https://community.jboss.org/people/ssilvert] modified the document:
"Using the CLI remote client jar"
To view the document, visit: https://community.jboss.org/docs/DOC-18795
--------------------------------------------------------------
If you want to connect to a remote JBoss AS7 instance without installing AS7 on your local machine, you can use the CLI remote client jar. It is called *jboss-cli-client.jar* and it is located in <JBOSS_HOME>/bin/client.
The *jboss-cli-client jar* can be used to remotely manage a JBoss AS instance with CLI or jconsole. Copy jboss-cli-client.jar to your client machine.
Even though the jboss-cli-client jar was added starting with AS7.2, it still works with older AS7 versions. So it's a good way to get the benefit of the latest CLI code.
h3. To Run CLI using jboss-cli-client.jar
java -jar <PATH TO jboss-cli-client.jar> [--help] [--version] [--controller=host:port]
[--gui] [--connect] [--file=file_path]
[--commands=command_or_operation1,command_or_operation2...]
[--command=command_or_operation]
[--user=username --password=password]
Use --help for an explanation of the CLI command line options.
h3. To Run jconsole using jboss-cli-client.jar
jconsole -J-Djava.class.path=<PATH TO jconsole.jar>;<PATH TO tools.jar>;<PATH TO jboss-cli-client.jar>
Path to jconsole.jar and tools.jar is typically <JAVA_HOME>/lib/jconsole.jar and <JAVA_HOME>/lib/tools.jar.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18795]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 2 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Primordial Boot Options
by Stan Silvert
Stan Silvert [https://community.jboss.org/people/ssilvert] commented on the document
"Primordial Boot Options"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48264#comment-11424
--------------------------------------------------
I like the "New Main Class" idea. I don't see the extra file in the root as a big problem. And I don't think the complexity of the final command matters at all because it is hidden from 99.999% of users.
But anything you can remove from the script means you can potentially remove it in several files: standalone.bat, standalone.sh, domain.bat, and domain.sh. That seems like a big win.
-1 on the shading though. I'd rather keep the ability to update/replace the two jars independently.
Stan
--------------------------------------------------
13 years, 2 months
[JBoss AS 7 Development] - Primordial Boot Options
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Primordial Boot Options"
To view the document, visit: https://community.jboss.org/docs/DOC-48264
--------------------------------------------------------------
On this page I want to lay out some alternative approaches to altering the AS 7.2 / EAP 6.1 boot to realize the objectives discussed in https://community.jboss.org/docs/DOC-47927
https://community.jboss.org/docs/DOC-47927.
h2. Primary goals:
1. To support the organization of modules as described on https://community.jboss.org/docs/DOC-47927 https://community.jboss.org/docs/DOC-47927, such that the modules that ship with AS 7.2 comprise the "distribution base" discussed on that document.
2. To ensure that when other valid "layered distributions" or "add-on"s install on top of that AS 7.2 distribution base they can place their modules in appropriate locations as described in https://community.jboss.org/docs/DOC-47927 https://community.jboss.org/docs/DOC-47927 and don't need to alter the startup scripts in order to have those modules become visible with the proper precedence.
3. To ensure the the $JBOSS_MODULE_PATH environment variable is left available for use by end users and isn't polluted with the various detailed paths discussed on https://community.jboss.org/docs/DOC-47927 https://community.jboss.org/docs/DOC-47927.
h2. Secondary goals:
These are things to consider while working to achieve the primary goal:
1. To eliminate as much as possible standard configuration settings from the startup scripts.
2. To organize any remaining script-based standard configuration settings to make them easily usable by tooling.
3. To avoid altering the programmatic launch of the AS such that existing tooling that launches the AS will not need to handle AS 7.2 / EAP 6.1 separately from how previous AS 7.1 / EAP 6.0 was handled.
Some of the secondary goals may prove contradictory.
h2. Current Boot
The critical aspects of our existing launch commands can be boiled down to the following for a standalone server and a managed domain host respectively:
java -jar jboss-modules.jar -mp modules org.jboss.as.standalone
java -jar jboss-modules.jar -mp modules org.jboss.as.process-controller
(The real command uses $JBOSS_HOME to create absolute paths. That is omitted in this document for brevity.)
The main() class invoked by the JVM is a JBoss Modules class in jboss-modules.jar. It reads the -mp command line argument to learn that modules are available under filesystem path "modules". It then loads either the org.jboss.as.standalone or the org.jboss.as.process-controller module, finds the class described as the "main" class in that module's module.xml file, loads it and invokes its main() method.
h2. Options:
The following options for how to do the boot come to mind:
h3. Specialized "Main" Modules
This the one that's been focused on recently.
The org.jboss.as.process-controller and org.jboss.as.standalone modules remain located as they currently are. They do not get placed in modules/layers/base as is described on the Layered Distributions wiki. As a result, a standard jboss-modules boot module loader can find them.
The code in those modules, however, changes significantly. Essentially it no longer particular concerns itself with those modules do today. Instead, it's sole concern is to figure out the detailed module path as described on the Layered Distributions wiki. It will figure that out and create a ModuleLoader that follows those rules. Using that ModuleLoader it will then load a *different* module located in modules/layers/base, find its main class, load that class and invoke its main() method. That class will execute the logic found in the current main classes.
An advantage to this is the existing programmatic launch command is completely unchanged.
The disadvantage is we leave modules located directly under modules. These modules have to be handled different from other modules, however. You can't override them in a patch via a different module. Instead the patch tool has to treat them as a bunch miscellaneous files (like it treats jboss-modules.jar.) This is mildly annoying because they are a special case for the patch generation and application tools. Also RPMs for layered products will have to account for these modules separately; they can't just create a simple symlink to the EAP RPM's modules/layers/base to pick up all the base modules.
With this approach there will likely be at least 3 of these specialized modules directly under modules/ -- org.jboss.as.standalone, org.jboss.as.process-controller and a 3rd, e.g org.jboss.as.boot, that contains the most of the code. The bulk of the code is common between the other two.
h3. Single Specialized "Main" Modules
This is a variant on the previous approach. The launch command becomes:
java -jar jboss-modules.jar -mp modules org.jboss.as.boot org.jboss.as.standalone
The goal here is to reduce the number of specialized "Main" modules to just one -- org.jboss.as.boot. It reads the next argument in the command (e.g. org.jboss.as.standalone) and uses it to decide what module to invoke.
This makes things a bit less messy in the modules/ dir but at the cost of changing the launch command.
h3.
h3. Specialized JBoss AS Boot Module Loader
This is the approach that was being followed on the initial work for the patching feature. The command becomes:
java -cp jboss-modules.jar:jboss-as-loader.jar -Dboot.module.loader=org.jboss.as.boot.ModuleLoader -jar jboss-modules.jar -mp modules org.jboss.as.standalone
The AS ships a jar "jboss-as-loader.jar" alongside jboss-modules.jar. The launch command places that jar on the classpath. JBoss Modules uses system property "boot.module.loader" to discover the classname of the ModuleLoader implementation it should use. The implementation the AS provides understands all the rules in the Layered Distributions wiki.
The downsides are an extra file in the root of the AS distribution and a change in the launch command.
h3. New Main Class
The AS stops using JBoss Modules as its main class. Instead we create our own main class, which does preliminary setup work and then calls JBoss Modules' main() class.
The launch command becomes:
java -cp jboss-modules.jar:jboss-as-boot.jar -jar jboss-as-boot.jar -mp modules org.jboss.as.standalone
Again, the downsides are an extra file in the root of the AS distribution and a change in the launch command.
A positive to this is the new main class can take over some processing that's currently done in the scripts. For example, including org.jboss.byteman in system property jboss.modules.system.pkgs. Also the -P processing requested at https://issues.jboss.org/browse/MODULES-117 could be done without requiring it to be added into jboss-modules itself.
h3. New Main Class with Shading
This is the same as the "New Main Class" approach, except we shade jboss-modules.jar into jboss-as-boot.jar in order to eliminate a jar. Launch command becomes:
java -jar jboss-as-boot.jar -mp modules org.jboss.as.standalone
Still a change in launch command though. The only way to get around the change in the launch command would be to call this shaded jar "jboss-modules.jar" which would be very, very ugly.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48264]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
13 years, 2 months
