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

[Jean-Francois Denise]

Thank-you.


On 09/11/2018 19:45, James Perkins wrote:
> 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 
> logging output.
There is some logic to attempt to load the module, if it succeeds, then 
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 at redhat.com <mailto:jdenise at redhat.com>> wrote:
>
>     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
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> -- 
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181112/5051f09f/attachment.html