Jboss Module.xml Slot
What is the need of “module.xml” and where to place it? What is “slot” and Why and When to define “slot” in our “module.xml” file? How to reference a module inside our webapplication for classloading purpose? A static module can declare dependencies in its module.xml file. A dynamic module can declare dependencies in the deployment’s MANIFEST.MF or jboss-deployment-structure.xml deployment descriptor. Implicit Dependencies. Implicit dependencies are added automatically by JBoss EAP when certain conditions or meta-data are found in a deployment.
by name. On the other hand, the module slot in JBoss Modules is
essentially an extension of the name, and is used mainly as a helper to
name parsing for things like the filesystem module loader to allow easy
multi-version or parallel installation support. A few projects use
slots for other purposes. In many module loaders, slots are not used at
all and are allowed to default to 'main'.
Among the changes coming to JBoss Modules for Java 9, my current plan
for this is to migrate towards the Java 9 way of doing things and
support only a general name field. For compatibility purposes, the
ModuleIdentifier API will continue to function, until/unless it is clear
that all major users have migrated off of it. It will work as a
frontend to plain String names - a ModuleIdentifier with name 'name' and
slot 'slot' will be translated behind the scenes as a module named
'name:slot'. A module with a slot of 'main' will be translated as just
'name'. A simple character escaping scheme will be employed to ensure
that there is a lossless two-way mapping from plain names to
ModuleIdentifier-style names, in the event that there is a ':' in the
name part of the ModuleIdentifier, though in practice this may not come
up much.
The existing module loaders can continue to function more or less as
they are. For filesystem modules using module.xml, the slot could still
be used by way of the compatibility syntax scheme above. The filesystem
module loader will continue to use the same file name mapping scheme for
now, using the aforementioned compatibility scheme to achieve the same
effect that slots do now; we can look at ways to transition off of that
later if it proves necessary to do so.
The deployment module loader in WildFly can be transitioned to using
plain names easily, and this can probably be done at any time. We can
keep WildFly management APIs which reference modules as they are for now
- if a slot is present, it could simply be appended to the given module
name after a dividing ':', otherwise the module name is used as-is. The
slot attributes could be deprecated at any time.
Overall though I think the best way of approaching the change is that we
start thinking of 'name:slot' as merely a ModuleLoader-specific name
syntax policy that some loaders use, and some do not. I suspect that
some module loaders will actively benefit from not having to deal with
the annoying possibility that a slot will be present and will not be the
expected 'main' value; having a simple unrestricted String name allows
each ModuleLoader to have complete control over their syntax policy,
which is something that JBoss Modules has been moving towards for some
time now.
Ultimately slots are a pretty limited tool and are already essentially a
facade over a plain name, with a very thin convenience class over the
top of it to implement a parsing policy. While many people have taken
advantage of slots in many ways, it is my view that moving this
logic/policy into each module loader will afford more flexibility than
does simply dividing names into two fields. The ModuleIdentifier class
could be preserved as a convenience, though I would not recommend its
use (hence deprecation), especially as it may map awkwardly into things
like Java 9 module-aware stack traces. However this is something that
can be discussed before any decision is reached.
The estimated time frame for these changes relates to the time frame and
progress of Java 9, so it is not clear at the moment exactly when this
must happen, but it is certain that the changes will definitely not
occur before WildFly 12. Hopefully this will give everyone enough time
to recover from the shock. :-)
Discussion!
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
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
Jboss Module.xml Sloths
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.)
Jboss Module.xml Slots
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
Jboss Module.xml Sloth
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.