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 > >
