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. Include the layering logic within JBoss Modules
If JBoss Modules natively supported the layering rules, this would be simplest. The AS
could simply reorganize its module directory layout and it would just work.
This is the current plan (Jan 18, 2013). The layering rules and patching mechanism we
propose for the AS are a valid general set of behavior that any complex application built
on jboss-modules might want to take advantage of, so David will build it in.
h3. Specialized "Main" Modules
This one was the initial focus but has proved impractical. It involves having most AS
modules no longer loaded by the JBoss Modules "boot module loader"; the boot
module loader simply loads 1 module which creates a different ModuleLoader to load
everything else. But I count 59 spots in the AS code base where the code is accessing
Module.getBootModuleLoader(), most, perhaps all of which would break with this approach.
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" Module
No longer under consideration for the same reason as the previous option.
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 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&a...]