<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi Cheng and Tomek and anyone else on wildfly-dev,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">One of the main things I&#39;m hoping we can do for WildFly 20 is get a first-cut (perhaps tech preview) implementation of bootable jar support.  A big part of the bootable jar story is the user using Galleon during the build of their application + server jar to produce a server customized to their requirements.  The key thing that makes that usable is having Galleon layers for the functionality they want.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">EJB is a big part of our functionality and we don&#39;t have layers for it yet, so I&#39;d like to get started on adding some. I&#39;ve been thinking some about what that might look like.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">A bit of context: a layer is a form of API, in that once we support a layer, if users use it to get some functionality, in the future they should be able to continue to use that layer and get that same functionality. So before introducing a layer we should be sure it does what we want, and also that it doesn&#39;t by mistake do &#39;extra&#39; things that we couldn&#39;t remove in the future.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Our EJB subsystem provides a wide variety of features, and I can think of a great number of use cases where users might want just some of them (say local SLSBs only) and would like a slimmer server without the rest. It would be great if in the future we could provide a number of layers to help with that.  But for the first cut at this I think we should keep it simple.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">(Also, the more layers we have the more testing permutations we need to deal with, which is doable but takes time.)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">If a user is trying to slim their server I think of four key things they want to do in descending order of importance:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">1) Eliminate unnecessary open ports.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">2) Eliminate unnecessary exposure</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">3) Eliminate jars, both to save filesystem footprint and to reduce any theoretical attack surface.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">4) Reduce configuration clutter and unnecessary services.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Given that I suggest we have the following layers:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">1) ejb3-lite. This is like what we provide in standalone.xml, but without the MDB instance pool or the remote connector resource.  (A webservices layer would depend on this.)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">2) ejb3. Builds (i.e. depends) on ejb3-lite and adds the discovery subsystem, the MDB pool and the remote connector resource. This looks what we provide in standalone-full.xml, except no IIOP integration.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">3) ejb3-iiop. Builds (i.e. depends) on *ejb3-lite* and adds the iiop subsystem plus the integration resource in the EJB3 subsystem. This *could* depend on *ejb3* instead, but that means EJB is unnecessarily exposed over the HTTP interface and a lot of dependencies are brought in for messaging integration.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">A user could provision ejb3 + ejb3-iiop and get the equivalent to what&#39;s in standalone-full.xml.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">There&#39;d be a couple ancillary layers as well:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">4) ejb-local-cache. This provides the infinispan subsystem resources related to local ejb caching (i.e. the ones in standalone.xml and standalone-full.xml.) The ejb3-lite layer *optionally* depends on this.  It&#39;s an optional dependency because the user when provisioning can *exclude* this layer and instead provision...</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">5) ejb-dist-cache. This provides the infinispan subsystem resources related to distributed ejb caching (i.e. the ones in standalone0ha.xml and standalone-full-ha.xml.)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">This pattern of &quot;exclude an optional local caching layer and add a distributed variant&quot; is how web session and jpa caching are handled in the layers for those features.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><a href="https://github.com/bstansberry/wildfly/commits/ejb-layers2">https://github.com/bstansberry/wildfly/commits/ejb-layers2</a> illustrates what the layer-specs could look like. (There&#39;s no effort there to adapt the subsystem to require fewer deps; it&#39;s just illustrating the config generation aspects.)<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I think the main work here (besides testing) would be examining what if any module dependencies in the org.jboss.as.ejb3 module could be made optional.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">TBH I don&#39;t see big FS footprint improvements coming out of these permutations. Big EJB dependencies include (in no particular order.)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">a) IIOP. But the TM uses IIOP libs so they will be there regardless.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">b) Remoting. It would be nice to be able to eliminate the need for remoting, e.g. for ejb3-lite if the user app isn&#39;t a remote ejb client. But that doesn&#39;t seem trivial and if a server is manageable remoting will be there anyway to support the CLI.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">c) JCA stuff. But if there&#39;s a datasource it&#39;s there anyway.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">d) Infinispan. A benefit of a future SLSB-only layer would be this dep could be eliminated. (But it might be used for web caching etc anyway.)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">e) Remote artemis integration.  This we do save if ejb3-lite is used.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">The general testing strategy we&#39;ve been doing as we&#39;ve developed layers is in testsuite/integration/smoke and basic we provision a server with a particular set of layers and then add a surefire execution that runs a subset of the tests that can work against the features in that server. That hasn&#39;t been too painful.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">WDYT?</div><div><br></div><div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">Best regards,</div><br></div><span class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">- Brian</span></div>