Jboss Module.xml Slot

For a general introduction to the smartics JBoss Modules Maven Plugin, please refer to Maven Plugin to generate a Modules Directory for JBoss AS 7 or to articles about JBoss modules on this blog. Side note: If you edit the XML files you may want to benefit from the XSD for the modules descriptor that is a useful tool within you IDE. Writing a Custom WildFly Module; Example.

1. Jboss Module.xml Sloths
2. Jboss Module.xml Slot Machine

Overview

JSF configuration is handled by the JSF subsystem. The JSF subsystem allows multiple JSF implementations to be installed on the same WildFly server. In particular, any version of Mojarra or MyFaces that implements spec level 2.1 or higher can be installed. For each JSF implementation, a new slot needs to be created under com.sun.jsf-impl, javax.faces.api, and org.jboss.as.jsf-injection. When the JSF subsystem starts up, it scans the module path to find all of the JSF implementations that have been installed. The default JSF implementation that WildFly should use is defined by the default-jsf-impl-slot attribute.

Installing a new JSF implementation manually

A new JSF implementation can be manually installed as follows:

Add a module slot for the new JSF implementation JAR

• Create the following directory structure under the WILDFLY_HOME/modules directory:
  WILDFLY_HOME/modules/com/sun/jsf-impl/<JSF_IMPL_NAME>-<JSF_VERSION>
  For example, for Mojarra 2.2.11, the above path would resolve to:
  WILDFLY_HOME/modules/com/sun/jsf-impl/mojarra-2.2.11

• Place the JSF implementation JAR in the <JSF_IMPL_NAME>-<JSF_VERSION> subdirectory. In the same subdirectory, add a module.xml file similar to the Mojarra or MyFaces template examples. Change the resource-root-path to the name of your JSF implementation JAR and fill in appropriate values for ${jsf-impl-name} and ${jsf-version}.

Add a module slot for the new JSF API JAR

• Create the following directory structure under the WILDFLY_HOME/modules directory:
  WILDFLY_HOME/modules/javax/faces/api/<JSF_IMPL_NAME>-<JSF_VERSION>

• Place the JSF API JAR in the <JSF_IMPL_NAME>-<JSF_VERSION> subdirectory. In the same subdirectory, add a module.xml file similar to the Mojarra or MyFaces template examples. Change the resource-root-path to the name of your JSF API JAR and fill in appropriate values for ${jsf-impl-name} and ${jsf-version}.

Add a module slot for the JSF injection JAR

• Create the following directory structure under the WILDFLY_HOME/modules directory:
  WILDFLY_HOME/modules/org/jboss/as/jsf-injection/<JSF_IMPL_NAME>-<JSF_VERSION>

• Copy the wildfly-jsf-injection JAR and the weld-core-jsf JAR from WILDFLY_HOME/modules/system/layers/base/org/jboss/as/jsf-injection/main to the <JSF_IMPL_NAME>-<JSF_VERSION> subdirectory.

• In the <JSF_IMPL_NAME>-<JSF_VERSION> subdirectory, add a module.xml file similar to the Mojarra or MyFaces template examples and fill in appropriate values for ${jsf-impl-name}, ${jsf-version}, ${version.jboss.as}, and ${version.weld.core}. (These last two placeholders depend on the versions of the wildfly-jsf-injection and weld-core-jsf JARs that were copied over in the previous step.)

For MyFaces only - add a module for the commons-digester JAR

• Create the following directory structure under the WILDFLY_HOME/modules directory:
  WILDFLY_HOME/modules/org/apache/commons/digester/main

• Place the commons-digester JAR in WILDFLY_HOME/modules/org/apache/commons/digester/main. In the main subdirectory, add a module.xml file similar to this template. Fill in the appropriate value for ${version.commons-digester}.

Start the server

After starting the server, the following CLI command can be used to verify that your new JSF implementation has been installed successfully. The new JSF implementation should appear in the output of this command.

Changing the default JSF implementation

The following CLI command can be used to make a newly installed JSF implementation the default JSF implementation used by WildFly:

A server restart will be required for this change to take effect.

Configuring a JSF app to use a non-default JSF implementation

A JSF app can be configured to use an installed JSF implementation that's not the default implementation by adding a org.jboss.jbossfaces.JSF_CONFIG_NAME context parameter to its web.xml file. For example, to indicate that a JSF app should use MyFaces 2.2.12 (assuming MyFaces 2.2.12 has been installed on the server), the following context parameter would need to be added:

If a JSF app does not specify this context parameter, the default JSF implementation will be used for that app.

Jboss Module.xml Sloths

• 4Naming Conventions
• 5Process

• How to create custom Modules in JBoss EAP 6 https://access.redhat.com/solutions/195403

https://github.com/NovaOrdis/playground/tree/master/jboss/wildfly/custom-module

Module Name

The module name is a dot-separated, fully qualified, unique, package name-like string. Conventionally, the name of the module coincides with the embedded top package, though nothing bad seems to happen it does not. Example: com.novaordis.playground.wildfly.custommodule.

Module JAR Name

Conventionally, it should be the condensed form of the module name, including the version string. Example custom-wildfly-module-1.0.jar.

Jboss Module.xml Slot Machine

Module Location

Write Code and Package It According the Naming Conventions

See Naming Conventions above.

Copy the JAR under WildFly's module Directory

See Module Location above.

Create a module.xml in the Same Module Directory

The content of the module.xml should be similar to:

Module's Dependencies

The module may have its own dependencies, which can be other JBoss modules, third party packages or JDK classes. Those must be declared as shown here:

Expressing Module Dependencies in module.xml

Make the Module Dependents Aware

In case of a web application, place a jboss-deployment-structure.xml similar to the example shown below under WEB-INF:

Create the EAP module as artifact of a dedicated 'eap-module' Maven module:

Deploying a Module with CLI