JBoss 7 directory structure explained

The first thing you’ll notice when you browse through the application server folders is that its file system is basically divided into two core parts: the dichotomy reflects the distinction between standalone servers and domain servers.

The concept of the domain server is not new in the market of application servers, however, it is introduced for the first time in JBoss AS as a way to manage and coordinate a set of instances of the application server. An application server node which is not configured as part of a domain is qualified as standalone server and it resembles in practice to a single instances of the application server you used in earlier releases.

we can see the one that the main file system is split in two: one section which is pertinent to domain servers and another which is relative to standalone servers.

The bin folder

This is where you start your application server instances. You can start a standalone server by launching the standalone.bat (standalone.sh for Linux users). In addition to the startup scripts, you can find the standalone.bat, which can be used to customize JBoss’ bootstrap processIf you are going to use a domain of servers, you will use the domain.bat script (domain.sh for Linux users). This shell script starts up a set of application server instances as specified by the domain configuration file. The bin folder also includes another useful script command, named jbossadmin. bat (jboss-admin.sh for Linux users), which starts the new interactive command-line interface. In addition, this folder contains the web services utility scripts (wsconsume.sh and wsprovide.sh) used to generate the web services definition language and the corresponding Java interfaces.

The docs folder

In spite of its name, this folder does not contain the server documentation, but two subfolders: the first one named licenses barely contains the licenses information for the application server and its dependencies. You might use the licenses.xml file as quick reference for finding out which are the version shipped with the default application server modules or dependencies. For example, JBoss AS 7 ships with the release 4.0.0.CR2 of Hibernate core libraries.

<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.0.CR2</version>
<licenses>
<license>
<name>GNU Lesser General Public License</name>
<url>http://www.gnu.org/licenses/lgpl-2.1.html</url>
<distribution>repo</distribution>
<comments>See discussion at http://hibernate.org/license for more details.</comments>
</license>
</licenses>
</dependency>

The other subfolder named schema contains the .xsd files which are used by the configuration as schema.

 

The domain folder

The next folder is the domain folder, which contains the domain structure, split across a set of folders: The configuration folder contains as you might imagine the configuration files. The main configuration file is domain.xml which contains all services which are used by the nodes of the domain. It also configures the socket-binding interfaces for all services. Along with it, the other key file is host.xml which is used to define the management aspects of the domain. The last file contained in the configuration folder is logging.properties which are used to define the logging format of the bootstrap process. The content folder is used as a repository to store deployed modules. The lib folder hosts the sub-folder ext, which is there to support Java SE/EE style “extensions”. Some of the application server deployers are able to scan this folder for additional libraries which are picked up by the local class loader; nevertheless this approach is not recommended and maintained only for compliance with the language specifications. The modules folder should be the one and only path for your libraries. The log folder contains as you might imagine the logging output of the domain. The file, by default, is truncated every time the server is rebooted. The servers folder holds a set of sub-folders for each server defined in the configuration file. The most useful directory contained beneath each server is the log folder which is the location where single instances emit their log. The data folder is used by the application server to store its runtime data, such as the transaction logging The tmp folder is a temporary location for some resource artifacts which is not a big issue for any of you.

The standalone folder

If you are running the application server in standalone mode, this is the part of the AS file system you will be interested in. Its structure is quite similar to the domain folder with the notable exception of a deployment folder. Let’s proceed with order. Just below the domain folder, you will find the following set of subdirectories. The configuration folder contains also the application server configuration files. As a matter of fact the application server ships with a set of different configuration files, each one using a different set of functionalities. Launching the standalone start-up script, by default, the standalone.xml configuration file will be used. Besides standalone.xml, this folder contains the logging.properties file, which is also about the logging of bootstrap process. The other file you will find within it, mgmt-users.properties, can be used to secure the management interfaces.

The data folder is used by the application server to store its runtime data, such as the transaction logging.

The deployments folder is the location in which users can place their deployment content (for example, WAR, EAR, JAR, SAR files) to have it automatically deployed into the server runtime. Users, particularly those running production systems, are encouraged to use the JBoss AS management APIs to upload and deploy deployment content instead of relying on the deployment scanner subsystem that periodically scans this directory.

The lib folder hosts the sub folder ext, which is used to define extensions of the application server. The same considerations for the domain’s lib path apply here. The log folder contains the logs emitted by the standalone instance of the application server. The default log file, named server.log, is truncated every time the server is rebooted. The tmp folder holds is used by JBoss Virtual File System as a temporary location for resource artifacts.

The welcome-content folder:

This directory contains the default page which is loaded when you surf on the home of your application server (http://localhost:8080). In terms of web server configuration, this is the Web root context.

The modules folder

Beneath the modules folder, you will find the application server’s set of libraries, which are a part of the server distribution.

Historically, JBoss AS releases used to manage their set of libraries in different ways. Lets recap to make some order. Earlier, Release 4.x was used to define the core server libraries into the JBOSS_HOME/server libraries. Thereafter, each server definition had its specific library into the server/<servername>/lib folder.

This approach was pretty simple this way; however, it led to a useless proliferation of libraries which were replicated in the default/all server distribution. The release 5.x and 6.x had the concept of the common/lib folder which was the main repository for all modules that were common to all server definitions. Each server distribution still contained a server/<servername>/lib path for the libraries that were specific to that server definition. Unchanged from the earlier release was the repository for core server modules comprised by JBOSS_HOME/server.

JBoss AS 7 follows a real modular approach deprecating all earlier approaches. The server bootstrap libraries are now located at the root of the application server. There you can find the jboss-modules.jar archive, which is all you need to bootstrap the new application server kernel, based on the JBoss modules. The application server modules are now defined beneath the modules folder, grouped in a set of subfolders each one dedicated to a set of resources. At first sight, this approach might seem less intuitive than previous releases; however, once accustomed to it, you will find it much easier to handle module installation/updates.

The following table resumes the diverse approaches used across different server releases:

4.x   : JBOSS_HOME/server JBOSS_HOME/server/<server>/lib

5.x – 6.x : JBOSS_HOME/server JBOSS_HOME/common/lib and JBOSS_HOME/server/<server>/lib

7.x   : JBOSS_HOME/jboss-modules.jar JBOSS_HOME/modules subfolders

Listing all the modules will take up too much space; however, the module repository layout is pretty much the same as the module name. For example, the org.jboss. as.ejb3 module will be found in org/jboss/as/ejb3 subfolder of the modules folder. In the last section of this chapter, we will see how modules are actually loaded by the application server.

Loading application server modules

Learning more about JBoss module is essential if you want to understand the next chapters that discuss about the server configuration. Basically, each module is a pluggable unit. As depicted by the following picture. JBoss modules can load libraries using two approaches:

• Using a static file system

• Using direct JAR execution

 

Using a static file system approach is the simplest way to load a module, and it’s used as a default when starting up the application server. It is based on the assumption that the filesystem reflects the name and version of modules used. All you need to provide to the environment is the location where modules are stored. So, for example, you could start a standalone instance of JBoss AS 7 using the following command:

java -jar jboss-modules.jar -mp “%JBOSS_HOME%\modules” org.jboss.as.standalone

The argument module path (-mp) actually points to the root directory (or directories), which will be searched by the default module loader for module definitions. A module is defined using a simple XML descriptor, like this:

<module xmlns="urn:jboss:module:1.0" name="org.jboss.msc">
<main-class name="org.jboss.msc.Version"/>
<resources>
<resource-root path="jboss-msc-1.0.0.Beta8.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="org.jboss.logging"/>
<module name="org.jboss.modules"/>
</dependencies>
</module>

Basically, a module definition contains two main elements: the resources defined in the module (and their path) and the module dependencies. The previous example is the module definition for the JBoss MSC module which is contained in the jbossmsc-1.0.0.Beta8.jar file and bears a dependency on javax.api, org.jboss.logging and org.jboss.modules module.

 

The other way to approach the module repository is by using direct JAR execution. This means that the module information, such as its dependencies, is contained in the MANIFEST file.

When the module is executed as a JAR file you just need to provide the name of your application module, which is packed in JAR file, and it will be picked up by JBoss modules:

java -jar jboss-modules.jar -jar your-app.jar

 

Then, in your application.jar, you might specify a set of module definitions, much the same way you did for flat filesystem modules. These definitions are contained in the META-INF/MANIFEST.MF file:

Main-Class: mypackage/MyClass

Dependencies: org.jboss.logging

For more information you can check the Jboss getting started Guide

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.