On Wed, Jun 12, 2019 at 11:11 AM Mark Struberg <strub...@yahoo.de.invalid> wrote:
> 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. > That did not seem very practical to me so the said code is quite Tomcat-like right now and most importantly it needs the fixes made in 9.0.21, so it won't work with any older Tomcat. If you really can take it over (and un-Tomcatize the code, I suppose), no problem. > > 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. > Ok, so I guess I don't need to do anything further in that area since you prefer to continue covering it. I'll move on to other items on my todo list then. Rémy > > 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 > >
