Jboss Module.xml Slot
Jboss Module.xml Slot Average ratng: 3,9/5 4301 reviews
- 4Naming Conventions
- 5Process
Jboss Module.xml Slot Machine
- 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
Code review; Project management; Integrations; Actions; Packages; Security. Tested on EAP 6.4. When creating a module for a custom loghandler, everything works fine if the module is package in default main slot, e.g. Module.xml; my.jar. No need to create 'module.xml' for each library. Create a single module and put all libraries there and mention it in resource-root. Also mention any module dependencies (if no, ignore it). Example module.xml.
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.
Jboss Module.xml Slots
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.
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
Retrieved from 'https://kb.novaordis.com/index.php?title=Writing_a_Custom_WildFly_Module&oldid=18036'
Java 9 modules do not have a concept of a slot, and are identified only
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
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