[wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon

[Jean-Francois Denise]

Hi,

in the galleon project, in a context where we would not provision a 
complete server but just a subset required to run a given configuration, 
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 of the 
subsystem module, so galleon has the risk to miss some of them.

As an example, in logging subsystem we have the following non optional 
injected modules :
"org.jboss.logging",
"org.apache.commons.logging",
"org.apache.log4j",
"org.slf4j",
"org.jboss.logging.jul-to-slf4j-stub"

Some of these modules are direct dependencies of logging subsystem, some 
others are indirect dependencies, others could be not present at all in 
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 new 
one  would have to be created.

There is also the case of optional injected module dependencies (eg: ee 
subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to 
treat them differently. When one is provisioning a server using galleon 
he can choose to exclude some packages from the provisioned server. 
Optional packages can be excluded without making the provisioned state 
invalid (as opposed to required package that can't be excluded). These 
optional implicit dependencies are typical usage of this, they are not 
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 present in 
JBOSS module.xml.

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 (eg: jmx 
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 dep 
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 module is 
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 (eg: 
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 part 
of another subsystem (so are not provisioned by another source) but are 
only meaningful if the other subsystem is present. We call these ones 
"passive" (eg: org.jboss.as.weld optional dependency on 
org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). 
"passive" are analyzed. If all their dependencies are present, then they 
are included. Some implicit optional dependencies can fall into this 
category (eg: org.jboss.jaxrs optional dep on 
org.jboss.resteasy.resteasy-validator-provider-11).

The passive optional dependencies would be advertised with 
RuntimeCapability.addAdditionalPassiveOptionalPackages(optional 
dependency package name).

So to summarize:

- RuntimeCapability.addAdditionalRequiredPackages for all required 
implicit modules

- RuntimeCapability.addAdditionalRequiredPackages to associate optional 
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 place to 
help galleon in this task? It would require a bit of analysis of the 
dependencies of your modules but the gain could be quite important. Some 
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.

JF