The main reason those modules are dependencies of the logging
subsystem is because they are not really required for the subsystem
itself with the exception of org.jboss.logging. Those module
dependencies are added to deployments for convenience. So really
they're not required at all unless the user is using one of those
logging frameworks and they want the logging subsystem to control the
There is some logic to attempt to load the module, if it succeeds,
the dependency is added as a required one. Could this be replaced by an
optional dependency and no module loading? These modules would have to
to be added thanks to addAdditionalOptionalPackages.
This may be somewhat of an edge case because if the user doesn't use,
say slf4j, then there is no real reason to include the dependency
unless of course another module uses it. I do wonder if we should
remove the org.jboss.logging.jul-to-slf4j-stub module and just put the
library as a resource root to org.slf4j, but that's slightly OT :)
On Fri, Nov 9, 2018 at 12:34 AM Jean-Francois Denise
<jdenise(a)redhat.com <mailto:email@example.com>> wrote:
in the galleon project, in a context where we would not provision a
complete server but just a subset required to run a given
we have identified a need for subsystems to advertise to the galleon
tooling some modules in addition to the modules galleon discover by
traversing the module dependency tree.
The first case is DeploymentProcessor injecting modules into the
deployment units (implicit modules).
The deployment injected ones are not required to be a dependency
subsystem module, so galleon has the risk to miss some of them.
As an example, in logging subsystem we have the following non
injected modules :
Some of these modules are direct dependencies of logging
others are indirect dependencies, others could be not present at
the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub).
So we are thinking at solving this issue in 2 possible ways:
1) Mandate that all injected modules become dependencies of the
subsystem module at the cost to load some useless modules at runtime.
2) Possibly better, make the subsystem to call
RuntimeCapability.addAdditionalRequiredPackages (package name being
module name) for each injected module. An existing capability or a
one would have to be created.
There is also the case of optional injected module dependencies
subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We
treat them differently. When one is provisioning a server using
he can choose to exclude some packages from the provisioned server.
Optional packages can be excluded without making the provisioned
invalid (as opposed to required package that can't be excluded).
optional implicit dependencies are typical usage of this, they are
required by the deployment unit to properly operate.
For these, we plan to use
RuntimeCapability.addAdditionalOptionalPackages. We can't make them
"optional" in JBoss module. When galleon provision a subset of the
server we don't include all optional dependencies.
This brings the case of provisioning of optional dependencies
We have identified multiple kind of optional dependencies.
1) The optional dependencies that are referencing modules only in use
when a feature is present in the configuration of the subsystem
subsystem optional dep on org.jboss.remoting-jmx due to
<remoting-connector/>, remoting subsystem optional dep on
io.undertow.core for <http-connector/>, elytron subsystem optional
on org.picketbox for <jacc-policy>)
In order to have these dependencies to be provisioned with the
subsystem, we can attach thanks to
RuntimeCapability.addAdditionalRequiredPackages the modules to the
feature. When the feature is present in the configuration, the
no more optional but required.
2) The optional dependencies that reference modules that are part of
another subsystems and only use if this other subsystem is present
org.jboss.as.jpa optional dep on org.jboss.as.ejb3,
org.jboss.as.transactions optional dep on org.jboss.remoting). These
ones are simply not taken into account
3) The optional dependencies that reference modules that are not
of another subsystem (so are not provisioned by another source)
only meaningful if the other subsystem is present. We call these ones
"passive" (eg: org.jboss.as.weld optional dependency on
"passive" are analyzed. If all their dependencies are present,
are included. Some implicit optional dependencies can fall into this
category (eg: org.jboss.jaxrs optional dep on
The passive optional dependencies would be advertised with
dependency package name).
So to summarize:
- RuntimeCapability.addAdditionalRequiredPackages for all required
- RuntimeCapability.addAdditionalRequiredPackages to associate
dependencies to a feature
- RuntimeCapability.addAdditionalOptionalPackages for all optional
implicit dependencies that are not passive
- RuntimeCapability.addAdditionalPassiveOptionalPackages for all
optional dependencies (implicit or not) that are passive
Is it something that subsystems owner would be ready to put in
help galleon in this task? It would require a bit of analysis of the
dependencies of your modules but the gain could be quite
early experimentation of this has shown a big reduction of the server
filesystem footprint (web server + cdi has been reduced from 156MB to
46MB). The runtime memory usage reduction is not that big, but less
modules being loaded we have a gain.
Thanks for reading.
wildfly-dev mailing list
James R. Perkins
JBoss by Red Hat
wildfly-dev mailing list