<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thank-you.<br>
</p>
<br>
<div class="moz-cite-prefix">On 09/11/2018 19:45, James Perkins
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADGwLpiL=AqLkYaiPrTJbSheGvymQa5DQQ54nOVMBN8X0D8oig@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">
<div dir="ltr">
<div>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.<br>
</div>
</div>
</div>
</blockquote>
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. <br>
<blockquote type="cite"
cite="mid:CADGwLpiL=AqLkYaiPrTJbSheGvymQa5DQQ54nOVMBN8X0D8oig@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>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 :)</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Nov 9, 2018 at 12:34 AM Jean-Francois
Denise <<a href="mailto:jdenise@redhat.com"
target="_blank" moz-do-not-send="true">jdenise@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
in the galleon project, in a context where we would not
provision a <br>
complete server but just a subset required to run a given
configuration, <br>
we have identified a need for subsystems to advertise to
the galleon <br>
tooling some modules in addition to the modules galleon
discover by <br>
traversing the module dependency tree.<br>
<br>
The first case is DeploymentProcessor injecting modules
into the <br>
deployment units (implicit modules).<br>
<br>
The deployment injected ones are not required to be a
dependency of the <br>
subsystem module, so galleon has the risk to miss some of
them.<br>
<br>
As an example, in logging subsystem we have the following
non optional <br>
injected modules :<br>
"org.jboss.logging",<br>
"org.apache.commons.logging",<br>
"org.apache.log4j",<br>
"org.slf4j",<br>
"org.jboss.logging.jul-to-slf4j-stub"<br>
<br>
Some of these modules are direct dependencies of logging
subsystem, some <br>
others are indirect dependencies, others could be not
present at all in <br>
the module dependency tree (eg:
org.jboss.logging.jul-to-slf4j-stub).<br>
<br>
So we are thinking at solving this issue in 2 possible
ways:<br>
<br>
1) Mandate that all injected modules become dependencies
of the <br>
subsystem module at the cost to load some useless modules
at runtime.<br>
<br>
2) Possibly better, make the subsystem to call <br>
RuntimeCapability.addAdditionalRequiredPackages (package
name being <br>
module name) for each injected module. An existing
capability or a new <br>
one would have to be created.<br>
<br>
There is also the case of optional injected module
dependencies (eg: ee <br>
subsystem org.glassfish.javax.el, org.eclipse.yasson,
...). We need to <br>
treat them differently. When one is provisioning a server
using galleon <br>
he can choose to exclude some packages from the
provisioned server. <br>
Optional packages can be excluded without making the
provisioned state <br>
invalid (as opposed to required package that can't be
excluded). These <br>
optional implicit dependencies are typical usage of this,
they are not <br>
required by the deployment unit to properly operate.<br>
<br>
For these, we plan to use <br>
RuntimeCapability.addAdditionalOptionalPackages. We can't
make them <br>
"optional" in JBoss module. When galleon provision a
subset of the <br>
server we don't include all optional dependencies.<br>
<br>
This brings the case of provisioning of optional
dependencies present in <br>
JBOSS module.xml.<br>
<br>
We have identified multiple kind of optional dependencies.<br>
<br>
1) The optional dependencies that are referencing modules
only in use <br>
when a feature is present in the configuration of the
subsystem (eg: jmx <br>
subsystem optional dep on org.jboss.remoting-jmx due to <br>
<remoting-connector/>, remoting subsystem optional
dep on <br>
io.undertow.core for <http-connector/>, elytron
subsystem optional dep <br>
on org.picketbox for <jacc-policy>)<br>
<br>
In order to have these dependencies to be provisioned with
the <br>
subsystem, we can attach thanks to <br>
RuntimeCapability.addAdditionalRequiredPackages the
modules to the <br>
feature. When the feature is present in the configuration,
the module is <br>
no more optional but required.<br>
<br>
2) The optional dependencies that reference modules that
are part of <br>
another subsystems and only use if this other subsystem is
present (eg: <br>
org.jboss.as.jpa optional dep on org.jboss.as.ejb3, <br>
org.jboss.as.transactions optional dep on
org.jboss.remoting). These <br>
ones are simply not taken into account<br>
<br>
3) The optional dependencies that reference modules that
are not part <br>
of another subsystem (so are not provisioned by another
source) but are <br>
only meaningful if the other subsystem is present. We call
these ones <br>
"passive" (eg: org.jboss.as.weld optional dependency on <br>
org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). <br>
"passive" are analyzed. If all their dependencies are
present, then they <br>
are included. Some implicit optional dependencies can fall
into this <br>
category (eg: org.jboss.jaxrs optional dep on <br>
org.jboss.resteasy.resteasy-validator-provider-11).<br>
<br>
The passive optional dependencies would be advertised with
<br>
RuntimeCapability.addAdditionalPassiveOptionalPackages(optional <br>
dependency package name).<br>
<br>
So to summarize:<br>
<br>
- RuntimeCapability.addAdditionalRequiredPackages for all
required <br>
implicit modules<br>
<br>
- RuntimeCapability.addAdditionalRequiredPackages to
associate optional <br>
dependencies to a feature<br>
<br>
- RuntimeCapability.addAdditionalOptionalPackages for all
optional <br>
implicit dependencies that are not passive<br>
<br>
- RuntimeCapability.addAdditionalPassiveOptionalPackages
for all <br>
optional dependencies (implicit or not) that are passive<br>
<br>
Is it something that subsystems owner would be ready to
put in place to <br>
help galleon in this task? It would require a bit of
analysis of the <br>
dependencies of your modules but the gain could be quite
important. Some <br>
early experimentation of this has shown a big reduction of
the server <br>
filesystem footprint (web server + cdi has been reduced
from 156MB to <br>
46MB). The runtime memory usage reduction is not that big,
but less <br>
modules being loaded we have a gain.<br>
<br>
Thanks for reading.<br>
<br>
JF<br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org"
target="_blank" moz-do-not-send="true">wildfly-dev@lists.jboss.org</a><br>
<a
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"
class="gmail-m_2190110884848930393gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>James R. Perkins</div>
<div>JBoss by Red Hat</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
</body>
</html>