<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 9, 2018 at 12:45 PM, James Perkins <span dir="ltr"><<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div><br></div><div>So this is this case from Jean-Francois' initial post:</div><div><br></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">"- RuntimeCapability.</span><wbr style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">addAdditionalOptionalPackages for all optional<span> </span></span><br style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">implicit dependencies that are not passive"</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(Note that it's only truly optional if the DUP registers it that way.)</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">If the logging subsystem doesn't actual use the module itself then it's module.xml would not record it as a dependency. This <span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">is the right thing to do regardless if the logging subsystem isn't accessing any resources from them.</span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></div><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.</div></div></div></blockquote><div><br></div><div>AIUI the idea is that by not including these in the logging subsystem module.xml but instead recording them in the management model definition via <span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">addAdditionalOptionalPackages, this information will end up in the galleon feature spec. Based on that galleon will provision the modules, but would allow the user to exclude them if they wanted to further optimize.</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I assume that for compatibility reasons we must provision them by default.</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div> I do wonder if we should remove the org.jboss.logging.jul-to-<wbr>slf4j-stub module and just put the library as a resource root to org.slf4j, but that's slightly OT :)</div><div><div class="h5"><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">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-<wbr>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-<wbr>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.<wbr>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.<wbr>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.<wbr>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|<wbr>beanvalidation|webservices|<wbr>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-<wbr>validator-provider-11).<br>
<br>
The passive optional dependencies would be advertised with <br>
RuntimeCapability.<wbr>addAdditionalPassiveOptionalPa<wbr>ckages(optional <br>
dependency package name).<br>
<br>
So to summarize:<br>
<br>
- RuntimeCapability.<wbr>addAdditionalRequiredPackages for all required <br>
implicit modules<br>
<br>
- RuntimeCapability.<wbr>addAdditionalRequiredPackages to associate optional <br>
dependencies to a feature<br>
<br>
- RuntimeCapability.<wbr>addAdditionalOptionalPackages for all optional <br>
implicit dependencies that are not passive<br>
<br>
- RuntimeCapability.<wbr>addAdditionalPassiveOptionalPa<wbr>ckages 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>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></blockquote></div><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr" class="m_8560592076550716847gmail-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></font></span></div></div>
<br>______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</div></div>