<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 3:44 AM Ondra Chaloupka &lt;<a href="mailto:ochaloup@redhat.com">ochaloup@redhat.com</a>&gt; 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"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 2:11 AM Brian Stansberry &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt; 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"><div dir="ltr"><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">Hi Cheng and Tomek and anyone else on wildfly-dev,</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">1) Eliminate unnecessary open ports.</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">2) Eliminate unnecessary exposure</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">3) Eliminate jars, both to save filesystem footprint and to reduce any theoretical attack surface.</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">4) Reduce configuration clutter and unnecessary services.</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">Given that I suggest we have the following layers:</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">A user could provision ejb3 + ejb3-iiop and get the equivalent to what&#39;s in standalone-full.xml.</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">There&#39;d be a couple ancillary layers as well:</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><a href="https://github.com/bstansberry/wildfly/commits/ejb-layers2" target="_blank">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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">a) IIOP. But the TM uses IIOP libs so they will be there regardless.</div></div></blockquote><div><br></div><div>Hi Brian,</div><div> <br></div><div>I&#39;m thinking longer about making the transaction manager module more granular and especially to make it possible to split the JTA in-VM non-IIOP operations from the IIOP version.</div><div>I assume this could be quite beneficial for the footprint improvements especially in connection to these EJB changes, right?</div><div>I need to investigate more on technical details but I think transactions could be stripped of at least three modules of JTA (non IIOP), JTS (JTA + IIOP) and CDI transactional handling.<br></div><div>How beneficial would you consider such stripping of the transaction subsystem?</div></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">It would be nice.  If I provision a webserver with datasource support and remote management capability, the disk footprint is ~ 74MB. Of that about 4-4.5 MB looks to be due to the ORB-related modules, primarily javax.orb.api.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">So cutting that out doesn&#39;t change the world but it&#39;s one of the bigger chunks and probably the biggest that has no intuitive relationship to what the server&#39;s intended feature set.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">Semi-tangent -- about 18 months ago I did some subsystem work related to configuring use of JTS using a management resource instead of just an attribute. That kind of thing would be needed to allow Galleon to know to provision JTS-related modules, as resources can provide that kind of wiring info to Galleon but attributes don&#39;t.  It was no big deal except some compatibility code so the old &#39;attribute&#39; style config still works. I put that on the shelf because there was no practical use on the horizon and we had many other priorities.  I&#39;ll dig that up and send you a link.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Ondra<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif">c) JCA stuff. But if there&#39;s a datasource it&#39;s there anyway.</div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif">e) Remote artemis integration.  This we do save if ejb3-lite is used.</div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,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 style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div style="font-family:&quot;trebuchet ms&quot;,sans-serif">WDYT?</div><div><br></div><div><div 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>
_______________________________________________<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/mailman/listinfo/wildfly-dev</a></blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>