JBoss 4.2.3.GA – Administration guide best practices

The JBoss AS 4.2.3 ships with the following directory structure for a given instance:

conf/     contains JBoss bootstrap configuration files
lib/      contains static libraries that are loaded on startup
deploy/   contains deployable resources (applications, xml files, jar files, ...)
...

When going to production, people just ships the JBoss AS as it is and deployments are operation on this directory structure directly. I think this is a bad practice and I personnaly strongly advice to separate the concerns and isolate application specific resources into separate and external folders:

  • these folders contain instance bootstrap resources and modifying or manipulating these resources can be tricky
  • Separating JBoss AS resources from application specific resources will make any deployment automation more easier
  • Isolating JBoss AS resources will make Docker-ization of a JBoss container much more easier too!

Hopefully this has been made possible by JBoss!

The deployment folder “./deploy”

The JBoss AS “deploy” folder of an instance ships with a certain number of applications (a EJB Deployer, a WEB deployer – namely Tomcat, JMX console …).
This folder is scanned on startup and is configured in the conf/jboss-service.xml file. You can add any number of external folders to the scanning component for application deployment on startup as well as for hot deployment. Locate the section below within the org.jboss.deployment.scanner.URLDeploymentScanner

    <attribute name="URLs">
         deploy/
    </attribute>

and just add you (external to jboss) applications specific deployment folder as follows:

    <attribute name="URLs">
         deploy/,
         /path_to_deployment_folder
    </attribute>

In Docker, this folder can be mapped as a Volume.

The configuration “./conf”

The ./conf folder, in addition to containing JBoss bootstrap configuration files can contain your application specific resources, these resources are added to the applications resources classpath by JBoss and can be loaded using, for example, using

MyClass.getResourceAsStream("/myresource");

You can define, through the command line an external folder to the loaders classpath as follows:

bin/run.sh --classpath=/path_to_resources_folder

You can put in this folder all the ressources (xml files, properties, … etc) the application will access through MyClass.getResourceAsStream("/myresource");.

In Docker, this folder can be mapped as a Volume.

The static libraries folder

The ./lib folder contains static libraries (loaded on startup), these libraries are necessary for JBoss default applications deployment and startup.
For your application libraries, you can either package them within the artifact (ear or war) – I strongly advice this approach – or you can add them as static library and be loaded on JBoss startup (this is mandatory if you want to deploy a .jar artifact for example as this latter cannot contain third party libraries).

You can define a separate and external libraries folder for you application third party libraries though command line as follows

bin/run.sh --library=path_to_libraries_folder

In Docker, this folder can be mapped as a Volume.

JBoss 4.2.3.GA command line options

Here is the list of JBoss 4.2.3.GA launch options from the MainClass of the bin/run.jar

-h, --help                    Show this help message
-V, --version                 Show version information
--                            Stop processing options
-D<name>[=<value>]            Set a system property
-d, --bootdir=<dir>           Set the boot patch directory; Must be absolute or url
-p, --patchdir=<dir>          Set the patch directory; Must be absolute or url
-n, --netboot=<url>           Boot from net with the given url as base
-c, --configuration=<name>    Set the server configuration name
-B, --bootlib=<filename>      Add an extra library to the front bootclasspath
-L, --library=<filename>      Add an extra library to the loaders classpath
-C, --classpath=<url>         Add an extra url to the loaders classpath
-P, --properties=<url>        Load system properties from the given url
-b, --host=<host or ip>       Bind address for all JBoss services
-g, --partition=<name>        HA Partition name (default=DefaultDomain)
-u, --udp=<ip>                UDP multicast address
-l, --log=<log4j|jdk>         Specify the logger plugin type

Running JBoss-4.2.3.GA on jdk 1.7 or higher

If you’ve got problems running JBoss-4.2.3 on JDK 1.7 version or higher, beacause of

java.lang.IllegalStateException: Cannot build JAXB context ... java.lang.StackTraceElement does not have a no-arg default constructor

Than this is for you!

You get in troubles running JBoss-4.2.3 on a JDK 1.7 or higher mainly because of the JaxWS API : starting from Java 1.7, the Throwable interface gets added a new method getSuppressed() and the JBoss 4.2.3 implementation (jbossws) is based on the Java 1.6 (or 1.5). The patch (that you can download here) allows to filter out that method from the ones that jbossws considers for JaxWS Exception mappings.

Patching it is very eay and strainght forward (thanks Lukasz) and concerns the single AbstractWrapperGenerator class of the jbossws-core.jar library.

You can download from the (github) repository the Java 1.6 compiled version (.class) or you can choose to recompile it by your own (the jbossws source code can be downloaded here). I strongly suggest to replace, from that source code, only the class of interest, namely the AbstractWrapperGenerator as explained in the readme file of the git repository. The recompilation requires you adding many (really many) jars to the project classpath. You can find here an exhaustive listing of the required jars (Many stand on the different JBoss 4.2.3 server folders and some can be found on Maven central repo).

References & links