<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 Wed, May 6, 2020 at 9:26 AM Cheng Fang <<a href="mailto:cfang@redhat.com">cfang@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"><div dir="ltr"><div style="font-family:georgia,serif;font-size:large"> </div><div style="font-family:georgia,serif;font-size:large">This is what we (ejb team) think after discussion. Brian's analysis in this thread seems pretty comprehensive and well thought out, and covers the majority of use cases of customized ejb subsystem. We are new to Galleon but will be working on it as per the above analysis. Also given that we are close to code freeze, we don't have an accurate estimate of what can be done in this release.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Apologies for taking so long to write that up. It's quite late for 20 (tbh later than I realized) and I don't want to create pressure to add things in a rush. My first post here wasn't worded well re that, so please don't worry about cramming things in.</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">Please feel free to ping Yeray Borges or I if you have questions.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><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:georgia,serif;font-size:large"><br></div><div style="font-family:georgia,serif;font-size:large">Richard mentioned that a few places in ejb3 subsystem will need to be improved to use capabilities to declare external dependencies, and he will be working on that to prepare for Galleon configuration.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I found the old branch I mentioned to Ondra, and I see it had a bit of capability stuff in there related to EJB-IIOP. (I believe because the JTS<->IIOP stuff involved capabilities and I probably tossed in EJB-IIOP as a thought experiment:</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">Anyway, here's that branch:</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/jts-iiop">https://github.com/bstansberry/wildfly/commits/jts-iiop</a><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">It's fairly out of date.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><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:georgia,serif;font-size:large"><br></div><div style="font-family:georgia,serif;font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 1:20 PM Cheng Fang <<a href="mailto:cfang@redhat.com" target="_blank">cfang@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"><div dir="ltr"><div style="font-family:georgia,serif;font-size:large">Hi Brian,</div><div style="font-family:georgia,serif;font-size:large"><br></div><div style="font-family:georgia,serif;font-size:large">We'll discuss it with the ejb team and get back to you.</div><div style="font-family:georgia,serif;font-size:large"><br></div><div style="font-family:georgia,serif;font-size:large">Cheng<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 3, 2020 at 8:10 PM Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@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"><div dir="ltr"><div style="font-family:"trebuchet ms",sans-serif">Hi Cheng and Tomek and anyone else on wildfly-dev,</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">One of the main things I'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:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">EJB is a big part of our functionality and we don't have layers for it yet, so I'd like to get started on adding some. I've been thinking some about what that might look like.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div 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't by mistake do 'extra' things that we couldn't remove in the future.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">1) Eliminate unnecessary open ports.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">2) Eliminate unnecessary exposure</div></div></blockquote></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">BTW, I didn't complete this sentence: I meant to say "Eliminate unnecessary exposure over shared sockets." Typically with WF that would mean 8080.</div><div class="gmail_default" style="font-family:"trebuchet ms",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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><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:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">3) Eliminate jars, both to save filesystem footprint and to reduce any theoretical attack surface.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">4) Reduce configuration clutter and unnecessary services.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">Given that I suggest we have the following layers:</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">A user could provision ejb3 + ejb3-iiop and get the equivalent to what's in standalone-full.xml.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">There'd be a couple ancillary layers as well:</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div 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's an optional dependency because the user when provisioning can *exclude* this layer and instead provision...</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">This pattern of "exclude an optional local caching layer and add a distributed variant" is how web session and jpa caching are handled in the layers for those features.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",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's no effort there to adapt the subsystem to require fewer deps; it's just illustrating the config generation aspects.)<br></div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div 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 style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">TBH I don't see big FS footprint improvements coming out of these permutations. Big EJB dependencies include (in no particular order.)</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">a) IIOP. But the TM uses IIOP libs so they will be there regardless.</div><div 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't a remote ejb client. But that doesn't seem trivial and if a server is manageable remoting will be there anyway to support the CLI.</div><div style="font-family:"trebuchet ms",sans-serif">c) JCA stuff. But if there's a datasource it's there anyway.</div><div 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 style="font-family:"trebuchet ms",sans-serif">e) Remote artemis integration. This we do save if ejb3-lite is used.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">The general testing strategy we've been doing as we'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't been too painful.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">WDYT?</div><div><br></div><div><div style="font-family:"trebuchet ms",sans-serif">Best regards,</div><br></div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">- Brian</span></div>
</blockquote></div>
</blockquote></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>