Red Hat JBoss Enterprise Application Platform Administration I

JBoss EAP 7 is based on a core infrastructure provided by the WildFly Core project that, among other tasks, manages the loading and activation of modules, following the architecture provided by the JBoss Modules project. A module basically provides Java code to be used by JBoss EAP services and by applications.

The following figure shows the main components inside JBoss EAP 7. The upper half of the diagram displays WildFly Core components (the JBoss EAP core), most of them modules themselves. The lower half shows modules provided by other JBoss community projects, which are integrated into the WildFly project and then productized and supported by Red Hat as JBoss EAP 7.

Figure 1.12: JBoss EAP 7 high-level architecture

In a traditional Java application server the class loading operation search for the Java classes in a hierarchical mode. The application server hierarchical mode mimics the behaviour of the Java Virtual Machine (JVM). From Java Standard Edition (Java SE) 1.2 to Java SE 8, the hierarchy of class loader was:

From Java SE 9 those three class loaders are slightly different, but the model is still hierarchical. In this model, when the Java application loads a Java class in memory, it tries to locate the class in its parents class loaders first. If the class is not present, then the Java application tries to locate the class in its own class loader.

Different implementations of other applications servers, such as Red Hat Web Server, based on Apache Tomcat, work by implementing its own hierarchy of class loaders. This different implementations can cause problems with some libraries that can package the same class, or overwrite some Java SE libraries. The same application, packaged in the same web application archive (WAR) file, can find class loading issues depending on the applications server implementation. Another common issue in the hierarchical class loader model, arises when two different applications package the same classes, but in different versions.

To avoid the hierarchical class loading model issues, in JBoss EAP the modules are loaded into an isolated class loader. Each module can only see classes from other modules when explicitly requested. This means you can implement a module without any concerns about potential conflicts with the implementation of other modules. All code running in JBoss EAP, including the code provided by the core, run inside modules. Application code is no exception, so applications are thus isolated between each other and from JBoss EAP services as well. JBoss EAP manages applications as dynamic modules.

The JBoss Modules architecture allows very fine-grained control of code visibility. An application can see a module that exposes a particular version of an API, and another application might see a second module that exposes a different version of the same API.

An application developer can control this visibility manually, which can be very useful in a few scenarios. But for most common cases, JBoss EAP 7 automatically decides with modules to expose to an application, based on its use of Jakarta EE APIs.

All modules available in an JBoss EAP 7 installation are directories inside the JBOSS_HOME/modules directory:

Inside one of the module directories, a module name is used to create a directory tree much like compiled Java classes. For example, the extension named org.wildfly.extension.undertow is under JBOSS_HOME/modules/system/layers as org/wildfly/extension/undertow.

Mode details about module file structure and how to add modules in a JBoss EAP 7 installation is presented later in this course.

A module that provides features and capabilities to the application server is called an extension. An extension does not only provide code, but also provides a management model, consisting of one or more subsystems, which enables the extension to be configured by the core.

The JBoss EAP core only loads and activates a module (and consequently an extension) when it is required, so features that are not in use do not waste memory or CPU. For example, a non-clustered JBoss EAP server instance does not have any clustering overhead.

Most of the features of JBoss EAP that relate to the deployment and configuration of servers and Jakarta EE applications are implemented through extensions. A subset of all the extensions provided by JBoss EAP is sufficient to implement the Jakarta EE Web Profile. Add a few more extensions, and JBoss EAP becomes compliant to the Jakarta EE Full Profile. But if the Jakarta EE web profile is too much for an application, it can use a smaller subset of the available extensions.

JBoss EAP 7 even provides a few extensions that add capabilities beyond the Jakarta EE 7 standards. An example of this is clustered singletons.

Extensions are added to a JBoss EAP instance by using the <extension> element, located at the beginning of the JBoss EAP main configuration file: standalone.xml, or domain.xml. The following XML listing shows some of the extensions declared in the default standalone.xml configuration file:

<?xml version="1.0" ?>
<server xmlns="urn:jboss:domain:4.1">
    <extensions>
        <extension module="org.jboss.as.clustering.infinispan"/>
        <extension module="org.jboss.as.clustering.jgroups"/>
        <extension module="org.jboss.as.connector"/>
        <extension module="org.jboss.as.ee"/>
        <extension module="org.jboss.as.ejb3"/>
... remainder of configuration file ...
</server>

Adding an extension to the configuration files does not make that extension module fully loaded and active. It only makes the extension manageable, meaning that the extension management model is loaded into memory and can be changed using the JBoss EAP 7 management tools.

For example, clustering configurations can be done if the related extensions are available, but the related modules are only loaded and activated when an application that requires clustering services is deployed. If no clustered application is deployed, them none of the extensions related to clustering are activated, even if the clustering extension management model was changed by the administrator.

An extension management model provides one or more subsystems, which can be configured and managed using the Management API provided by the core, by using the Management Console and the Management CLI. When an extension is added to a JBoss EAP instance, the capabilities and attributes of the subsystems provided by the extension management model are configured within the <subsystem> element in the JBoss EAP configuration file.

Most of the time, an extension module provides a single subsystem, as illustrated by the following figure:

Figure 1.13: JBoss EAP 7 Extensions and Subsystems

For example, the org.jboss.as.jpa extension provides the jpa subsystem. This subsystem configuration, in the default standalone.xml configuration file, looks like:

<subsystem xmlns="urn:jboss:domain:jpa:2.0">
    <jpa default-extended-persistence-inheritance="DEEP"/>
</subsystem>

The most commonly used subsystems can be configured using easy forms and assistants provided by the Management Console. All subsystems can be configured using the CLI, so usually there is no need to edit the XML directly to configure a subsystem.

The elements that appear within a subsystem are entirely unique to that particular subsystem. In fact, each subsystem has its own XML schema to define what is allowed within its <subsystem> element. All JBoss EAP 7 subsystem schema definitions can be found in the JBOSS_HOME/docs/schema directory.

<subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/>

A subsystem configuration does not stand by itself in the JBoss EAP 7 configuration files. A set of subsystem configurations is grouped inside a <profile> element.

The standalone server instance configuration file standalone.xml contains a single, anonymous, profile definition. The domain.xml managed domain configuration file contains four pre-defined profiles by defauilt, that should satisfy most use cases for applications deployed on JBoss EAP:

Figure 1.14: JBoss EAP 7 profiles

The provided default profiles can be in use by different server instances in the same managed domain, but profiles are not associated directly to server instances. Server instances are grouped. The profile is associated to the group.

JBoss EAP profiles are supposed to be customized to a particular application and environment needs, so two real-world standalone server instances probably have different profiles, containing different subsystem configurations.

In a managed domain, the administrator can create new profiles, either from scratch, or cloned from the ones provided, and then customize the new profiles before associating them to their respective groups. A profile can also be a child of another profile, thus inheriting the subsystem configuration from its parent profile, so common configurations can be shared and maintained in a single place.

In a standalone server instance, the single anonymous profile must be customized. This course later shows how to start a standalone server instance by using a configuration file named something other than standalone.xml, so the original file can be preserved as a reference.

As a JBoss EAP system administrator, you configure and mantain the subsystems present in your profiles, or their equivalents in the standalone mode. The administrator operations for extensions are less frequent.