<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 12, 2018 at 7:28 AM, Jean-Francois Denise <span dir="ltr"><<a href="mailto:jdenise@redhat.com" target="_blank">jdenise@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 text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<p><br>
</p>
<br>
<div class="m_167566970330334772moz-cite-prefix">On 09/11/2018 18:32, Brian Stansberry
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 9, 2018 at 2:30 AM,
Jean-Francois Denise <span dir="ltr"><<a href="mailto:jdenise@redhat.com" target="_blank">jdenise@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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-slf4<wbr>j-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<wbr>-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.addAdditiona<wbr>lRequiredPackages
(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.addAdditiona<wbr>lOptionalPackages. 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.addAdditiona<wbr>lRequiredPackages 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|bean<wbr>validation|webservices|transac<wbr>tions).
<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-va<wbr>lidator-provider-11).<br>
<br>
The passive optional dependencies would be advertised with
<br>
RuntimeCapability.addAdditiona<wbr>lPassiveOptionalPackages(<wbr>optional
<br>
dependency package name).<br>
<br>
So to summarize:<br>
<br>
- RuntimeCapability.addAdditiona<wbr>lRequiredPackages for
all required <br>
implicit modules<br>
<br>
- RuntimeCapability.addAdditiona<wbr>lRequiredPackages to
associate optional <br>
dependencies to a feature<br>
<br>
- RuntimeCapability.addAdditiona<wbr>lOptionalPackages for
all optional <br>
implicit dependencies that are not passive<br>
<br>
- RuntimeCapability.addAdditiona<wbr>lPassiveOptionalPackages
for all <br>
optional dependencies (implicit or not) that are passive<br>
</blockquote>
<div><br>
</div>
<div>A good question Alexey raised is whether the capability
is the right concept for encapsulating this information.</div>
<div><br>
</div>
<div>In the end the key point is that the information ends
up in the galleon feature-spec. That's the thing that
encapsulates the configuration elements and the packages
(i.e. fs content) that are needed to provide a feature.
It's the feature that needs the package. We generate the
galleon feature specs from our management model
information. When in WF 13 we hit the first must-implement
use case for getting additional package info into a
feature spec I kind of arbitrarily picked
'RuntimeCapability' as the place to record that. It was a
reasonable enough choice for that one use case but isn't
great otherwise.</div>
<div><br>
</div>
<div>The alternative is to record this data in the
ResourceDefinition, which is the primary source of the
data that's used in the feature spec generation.</div>
<div><br>
</div>
<div>The conceptual argument is a capability is all about a
named provider of a contract that other elements of the
server can rely on; e.g. some MSC Service with a
particular value type that will be exposed. But this
additional package stuff isn't really about that contract,
it's about other things that will be done that likely are
not relevant to other elements of the system.</div>
<div><br>
</div>
<div>A hint of a design smell would be if we end up creating
RuntimeCapability instances for no other reason than to
record this additional package information. Something I
could see happening with this logging case you mentioned
at the start.</div>
<div><br>
</div>
<div>I don't think ResourceDefinition has this problem.</div>
</div>
</div>
</div>
</blockquote></div></div>
I have introduced artificial capabilities in ee, jaxrs and weld
(subsystems that are targeted by the demo) to add additional
packages. It seems that it would be common case. So it is actually
smelly.</div></blockquote><div><br></div><div>Note though that all 3 of those subsystems are lacking capabilities for things they provide that other subsystems use. Or perhaps in the jaxrs case a private one that lets it require/use capabilities from other subsystems. (Yeray is working on weld.) IOW it's possible you're not really adding artificial capabilities, you're just bumping into the missing ones. ;)</div><div><br></div><div>^^^ is just an FYI comment though. I have little doubt we'll find artificial capabilities and it's possible ee, jaxrs, weld would have them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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. </blockquote>
<div><br>
</div>
<div>Please don't let my point above derail consideration of
this question. Use of ResourceDefinition vs
RuntimeCapability is a relatively small detail. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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/mailma<wbr>n/listinfo/wildfly-dev</a></blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_167566970330334772gmail_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>
</blockquote>
<br>
</span></div>
</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>