Hi folks! Really happy to see so much love and interest for all those awesome ASF projects!
Rémy's enhancements are great - the better and cleaner the integration, the better for all those projects. But Romain and David are also correct: it's very easy to become a committer on all the involved projects, especially for people known to deliver outstanding code and to be excellent community players! So at the end I really don't care much in which project stuff ends up. There are just a few ideas I'd like to have you think about: A.) There should be a clear 'dependency graph'. This is not so much a maven issue but really more a question of clear design. Tomcat is clearly the foundation of an EE server. It provides the ClassLoader setup, the servlet engine, etc. Tomcat provides abstract ways to integrate whatever wants to integrate with it via abstraction mechanisms. This might be CDI or Spring or Guice, or whatever! On top of this comes the CDI container who manages the instances. So all those parts live in OWB. Including the integration. So I'd keep the Tomcat integration as part of OWB. Even further up in the chain is Meecrowave as smallish Tomcat + CXF + CDI container and TomEE as fully blown JavaEE server. Having a build reference to TomEE or OWB in Tomcat would introduce cycles in our builds. This is not really a good thing. B.) We should also try to keep code and responsibilities at a single place and shall try to avoid duplications. This has nothing to do with 'ownership' - shuch a concept doesn't exist at the ASF anyway. But it has a lot to do with users knowing exactly where to look at if they are searching for a bug or even want to contribute a new feature. makes sense? txs and LieGrue, strub > Am 12.06.2019 um 08:31 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Hell Rémy, > > I commented inline > > Le mar. 11 juin 2019 à 23:29, Rémy Maucherat <r...@apache.org> a écrit : > On Tue, Jun 11, 2019 at 9:49 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > My 2cts would be that we have the luck to be fully ASF here so each project > can likely get back its missing piece(s) and we stay overall consistent > instead of creating yet another fork in our beloved foundation (we already > have some concurrent servers or even jdbc pools which does not help much user > land). > > @Rémy do you track the issues you encounter somewhere? > For instance "CXF is not user friendly" but once you have CDI you get CXF set > up just adding a servlet. Here, an initializer would have been friendly but > then you would encounter the servlet initializer ordering issue. > > Ok :) > > So: > - When downloading CXF, I'm facing a myriad of JARs, and I cannot really > figure out what's mandatory (there's a WHICH_JARS file, so that cannot be > that good). > > Depends, if you use maven it is fine ;). > > Joke apart, and assuming you grabbed the spec yourself (geronimo, javax or > jakarta jars) you just need: > > org.apache.cxf:cxf-core:3.3.2 > org.apache.cxf:cxf-rt-security:3.3.2 > org.apache.cxf:cxf-rt-transports-http:3.3.2 > org.apache.cxf:cxf-rt-frontend-jaxrs:3.3.2 > org.apache.cxf:cxf-integration-cdi:3.3.2 > org.apache.cxf:cxf-rt-rs-client:3.3.2 (optional but if you target > Microprofile you need it) > > - (Ok I figured it out) Looking at the integration(s), I quickly notice there > are plenty I can use: cxf-integration-cdi, cxf-rt-rs-http-sci and > cxf-rt-transports-http (did I miss any ?). They all need that I define a > Servlet it seems (no idea why at least some of these don't do it for me). > > There are two main concepts: the integration (cdi, spring, blueprint, ....) > and the transport (http, jms, ...). Http transport goes through the servlet > and the integration relies on the transport to forward the messages (request) > to the CXF server which does the link with the beans. > > - After getting somewhere and trying a mp health test with your Geronimo > Health CDI bundle, I got: > 11-Jun-2019 17:28:34.004 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both > org.apache.geronimo.microprofile.common.jaxrs.HealthChecksEndpoint#getChecks > and > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint#getChecks > are equal candidates for handling the current request which can lead to > unpredictable results > 11-Jun-2019 17:28:34.016 WARNING [http-nio2-8080-exec-2] > org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper.toResponse > javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error > at > org.apache.cxf.jaxrs.utils.SpecExceptions.toInternalServerErrorException(SpecExceptions.java:79) > at > org.apache.cxf.jaxrs.utils.ExceptionUtils.toInternalServerErrorException(ExceptionUtils.java:111) > at > org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1450) > at > org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.createInstance(PerRequestResourceProvider.java:89) > at > org.apache.cxf.jaxrs.lifecycle.PerRequestResourceProvider.getInstance(PerRequestResourceProvider.java:78) > at org.apache.cxf.jaxrs.JAXRSInvoker.getServiceObject(JAXRSInvoker.java:420) > at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101) > ... > Caused by: java.lang.IllegalAccessException: Class > org.apache.cxf.jaxrs.utils.InjectionUtils can not access a member of class > org.apache.geronimo.microprofile.impl.health.cdi.CdiHealthChecksEndpoint with > modifiers "private" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102) > at > java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288) > at java.lang.reflect.Method.invoke(Method.java:491) > at > org.apache.cxf.jaxrs.utils.InjectionUtils.invokeLifeCycleMethod(InjectionUtils.java:1442) > ... 47 more > > That's where I am right now. The way to use CXF with Tomcat should be more > obvious. > > Geronimo Health has a common and a cdi modules (cdi one being not suffixed in > terms of naming). Both are exactly the same except cdi one uses CDI beans for > the wiring and common is reusable in an OSGi container. > Common is not intended to be scanned. > I will add a scan=none in the jar since it is not done today and leads to > that issue if not excluded from the scanned jar - can be done through > openwebbeans.properties. > > -> https://issues.apache.org/jira/browse/GERONIMO-6734 if you want to give > another try with a snapshot > > > OWB did not have most of these issues, the amount of libraries is manageable > and the integration was labelled as "tomcat7". The main issue with OWB is > that integration had issues [it needed some adjustments in Tomcat to avoid > instance manager replacement timing issues; other more cosmetic problems were > the use of both Catalina internal components and Servlet level components, an > integration should try to choose one or the other unless there's a > showstopper which forces both], so I tried to modernize and improve it. > > Not needed but owb-web mainly intends to be portable so relies on servlet. > Not sure we would gain a lot moving it to catalina but not technical blocker > AFAIK > > > > In other words I wonder if we can't cumulate our efforts instead of working > isolated and moreover if we can avoid to split the code and deliverables more > than necessary - sounds like overlapping will be very high without more > details. > > I understand but CXF has too many constraints like the need to support many > many different kind of deployments and uses, so I'm not really blaming anyone > here. > > Well, it can be improove so no issue blaming it while it converges ;). > For example, I'm happy we encourage CXF to clarify its status on the > dependencies and modularity (core can be split a loootttt), dependencies are > very opiniated and transitive even when sometimes it shouldn't (spec should > be a dedicated pom easily excludable IMHO etc), > Also note that Wink (~fork from CXF) kinf of fail to simplify it keeping a > living ecosystem - > https://svn.apache.org/repos/infra/websites/production/wink/content/index.html > - this is why interacting can be sane here IMHO. > > > > Do we have a functional showcase app already? Can help building one if needed. > Do you have an idea of where you want to land (in terms of config + > deliverables)? > > Yes, ok. So for OWB as an example, here's what I have: > - Use Tomcat 9.0.21. > - Add <Listener className="org.apache.tomcat.webbeans.OpenWebBeansListener" > optional="true" /> to the <Server> element in server.xml. If OWB is not > present, the missing dependency of the listener will be logged as INFO > (without causing further problems). The context listener can also be > configured in conf/context.xml and it would apply to all webapps, but I > prefer avoiding this if possible (it's more hidden). > > Open question on tomcat side: I never really understood why we can't have SPI > listeners (Server and Context levels), I understand it as being a legacy part > of the impl, is it time to revisit it? > Typically I would have OpenWebBeansListener and a ServiceLoader auto > installing it. > The issue here - we had it on TomEE - is how you select it is enabled > explicitly or disabled explicitly since you do it on an instance. > In TomEE we used a context param but i'm sure a context listener can do the > trick as well. > > - Add the JAR from tomcat-owb to the lib folder, then this should CDI enable > all webapps. One thing I'm not sure about yet is the separate javax.* JARs, > so let's ignore that "detail" for now ... > - The integration can also be used at the individual webapp level (as before) > using context.xml. > > Is it needed? What it brings is only the servlet component integration > (injections) AFAIK - since the other integration is the principal and this > one can be done through a filter in owb-web "portably". > So if we can configure the instance manager from the context.xml then we > would be good and not need anything else - assuming activating it from the > webapp is equivalent to letting the user run it from the webapp which is > already done by several users. > > - It only uses Catalina components. > > Hmm, Tomcat moves valves to filters so why would we revert it for its CDI > integration? Not sure I got this one right. > > Does that look better to you ? > > Getting there with CXF is harder. > > > Answering both can be a way to move forward and see how we can converge. > To complete David's answer, I kind of see that even without integrating some > EE things in Tomcat itself, it can benefit to TomEE and enable it to align > even more on Tomcat in terms of user facing configuration for instance. > > Right. > > Rémy > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book > > > Le mar. 11 juin 2019 à 21:22, Rémy Maucherat <r...@apache.org> a écrit : > Hi David, > > On Tue, Jun 11, 2019 at 8:37 PM David Blevins <david.blev...@gmail.com> wrote: > Hi All, > > At a high level, is there a desire to start supporting more "EE" like specs > such as CDI, JAX-RS, JPA, etc? > > Completely understood if the answer is "depends." I suspect it would depend > on if the code is clean and light in Tomcat spirit. > > Ok, so the plan (my plan, actually) here is that I noticed CDI (and JAX-RS) > is the building block of many other APIs (like the Microprofile), so there's > a need to be able to use it in a "clean and light [and] in Tomcat spirit" way > (as you said). I had a look at OWB and CXF and while the support is there, it > needs some work (especially for the latter) and is certainly not user > friendly (again, esp for the latter). Note that the work is also in Tomcat > itself, since I'm in a good position to make changes and improvements as > needed. > > As for the answer, it would still be "no" at this point, since at most these > could be considered as a couple extra optional modules like the jdbc pool, or > maybe "build them yourself" poms. > > > I write this not from the perspective of "let's move a bunch of TomEE code > into Tomcat", but more of "let's write cleaner newer code in Tomcat and > retire equivalent TomEE code." > > That's not a specific proposal, just curious if appetite has developed in > recent years to entertain tip-toeing beyond the same set of specs. > > Rémy > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > > > On Jun 11, 2019, at 8:06 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > > > > > Le mar. 11 juin 2019 à 16:57, Rémy Maucherat <r...@apache.org> a écrit : > > On Thu, May 30, 2019 at 9:35 AM Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > Once done it can be hosted on both side.Owb has the advantage to be know by > > users, tomcat to be a more natural home for an integration. At the end it > > is mainly synchronizing both projects for a consistent communication and > > code "move" IMHO. > > > > For deep tomcat/cxf integration, you can use > > http://svn.apache.org/repos/asf/openwebbeans/meecrowave/trunk/ - core > > module. Technically it uses an embedded flavor but it would be easy to move > > to a standalone one through a listener based on a small refactoring in > > Meecrowave#start. The good part are the lifecycle and scanning integrations > > + the tooling to make testing and dev simple - > > http://openwebbeans.apache.org/meecrowave/. > > > > Ok, I think things look reasonably good using CDI extensions (looking at > > the Geronimo mp implementation you did) except the default CXF "servlet" > > integration. I think right now the "servlet" integration from the > > cxf-rt-transports-http package is "bad" and that the one from Meecrowave > > (in org.apache.meecrowave.cxf) is more likely to be the way to go (it > > derives from cxf-integration-cdi). > > > > So this looks a lot closer to Meecrowave than I originally expected, with a > > lot of "buts" though: > > - Meecrowave feels a lot like "Tomcat for Meecrowave" while the goal here > > is a "Meecrowave for Tomcat" > > > > Guess this one can converge - at least for TomEE it did and we have a tons > > of flavors, I dont see a blocker to unify it here to. > > > > - The JAR has all of Tomcat, log4j, API JARs, etc, while it should here be > > based off Tomcat, the javax APIs and OWB already present in the Tomcat OWB > > implementation JAR (the classic "tomcat7" or the modernized "tomcat-owb") > > > > The jar is just one flavor of meecrowave - assuming you reference the > > fatjar, you should still be able to use it as plain unitary dependencies. > > The missing part here is to extract from Meecrowave master class all the > > logic to "glue" the stack in Tomcat (mainly extracting it in a Listener I > > guess and ignoring the specific launcher config?) > > > > - log4j would need to be removed as well > > > > It is already supported, in this IT we drop log4j, johnzon, cxf: > > https://github.com/apache/meecrowave/blob/trunk/integration-tests/no-cxf/pom.xml#L32 > > > > - plenty of configuration files and options in the JARs, but I guess that's > > the way it is since all the subcomponents are so flexible > > > > Yep, but all are also settable from a listener or a centralized file, we > > are really free here. > > > > > > > > > > More technically: openwebbeans does not need properties files you can pass > > Properties when you create the WebBeansContext, this is what tomee does. > > Same for cxf and its bus ;). > > > > Ok, I'll have a look at that, it's better than properties files (but > > similar). > > > > Biggest short term challenge is to align scanners but it is very doable, > > long term it is to drop big core jars in all 3 libs for smaller bundles ;). > > > > Ok. > > > > Feel free to shout if you need help or more precise pointers. > > > > Rémy > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
