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