Hi guys, Interesting discussion. I'd love to see Karaf 4.3 asap.
As (mostly) a user of Pax Web, I'm wondering if just focusing on Jetty instead of supporting both Jetty & Tomcat could make things faster and maybe easier to integration test? I'm sure there are use cases for Tomcat that I'm not aware of but I'm wondering what they are? As a Karaf user, my biggest need is for a "global" interception mechanism on the HTTP service to be able to build filters for security, CSRF, etc... which are things that Pax Web doesn't support right now. Regards, Serge... Serge Huber CTO & Co-Founder T +41 22 361 3424 9 route des Jeunes | 1227 Acacias | Switzerland jahia.com <http://www.jahia.com/> SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER <https://twitter.com/sergehuber> | VCARD <http://www.jahia.com/vcard/HuberSerge.vcf> > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation. On Tue, Jul 7, 2020 at 12:23 PM Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: > Hello > > The problem with Pax-Web 8 and R7 compatibility is mostly related to ... > Pax-Web 7 (and 6) not being R6 compatible at all... > > Indeed - the refactoring was very ambitious - 1st, I didn't want to get rid > of all the huge work and design of Pax Web, 2nd, I though it'll be > comparable to my previous Pax Logging refactoring (where among others I've > increased number of real integration tests from 0 to 100+). > > I'm working now on "resource and welcome file handling" - and while > "welcome files" are not covered at all in Whiteboard/HttpService specs, Pax > Web is known to support them - so not having them would be a regression. > > I hope to have working resources/welcome files implementation this week - > just check the related test size to see what I'm talking about: > > https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663 > (with similar tests for Tomcat and Undertow). > > After resources/welcome-files, the big remaining thing is > pax-web-extender-war, however the refactoring will be minimal, because the > biggest changes were related to model (pax-web-spi), pax-web-runtime and > whiteboard trackers. > > For now, master-improvements branch is in a state where chance for merge > conflict is minimal (for some time initially I did really huge changes, > removals and moves of the files/packages). > > Also, the most important integration tests are now in the process of moving > (in other words - those that are moved, work). > > During my work I have also created some serious issues like: > - https://github.com/eclipse-ee4j/servlet-api/issues/300 > - https://github.com/eclipse/jetty.project/pull/5025 > > I'm aware that R8 is coming, but when we have working R7 implementation (or > rather R6 implementation in the first place), it'd be a matter of ~2 weeks > to implement R8 on top of working R7. > > So, thanks for patience, sorry for delay and please help if you like ;) > > regards > Grzegorz Grzybek > > wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <j...@nanthrax.net> napisał(a): > > > Hi, > > > > See my comment inline > > > > > Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rmannibu...@gmail.com> a > > écrit : > > > > > > Hi JB, > > > > > > I see more issues using felix http: > > > > > > 1. it only supports felix today AFAIK which directly impacts the > > production > > > since then your monitoring/observability/instrumentation can be to redo > > so > > > for me it is way more impacting than the dev side - and more vicious > > > > Good point, we can have impact with Equinox, true. > > > > > 2. felix is a fatjar so you can't upgrade jetty when needed which is > > also a > > > big loss compared to not having R7 IMHO > > > > That’s a discussion standpoint. Having a fat jar can be seen as a good > > point as upgrading Jetty (or Tomcat, or undertow) is not always (never > ;)) > > "smooth" at Pax Web. > > > > > > > > How far is paxweb from R7? Not being 100% compliant is fine IMO while: > > > a. it can be manually switched to a compliant impl if required > > > b. there is no regression from previous version > > > > > > > I think we are pretty close just for R7, but we also started a large > > refactoring (maybe it was too "ambitious"). > > So, another approach would by to start from Pax Web 7.2.x and just update > > the minimal set to R7 (new HTTP service). > > > > Regards > > JB > > > > > Indeed just my 2cts, > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <j...@nanthrax.net> a > > > écrit : > > > > > >> Hi everyone, > > >> > > >> It’s more than a year now that we started Apache Karaf 4.3.0 release > > >> process, fully supporting OSGi R7. > > >> > > >> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m > > >> concerned about that as R8 will be there and we will have issue in Pax > > Web > > >> again. > > >> > > >> Greg started a huge effort heading to Pax Web 8.0.0 with a large > > >> refactoring. > > >> However, the process is long and painful. > > >> So, I think it’s fair to have a discussion about the HTTP service in > > Karaf > > >> and "relationship" with Pax Web. > > >> > > >> I see three options for Karaf 4.3.0: > > >> > > >> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no > > >> brainer, we can move forward. > > >> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by > > >> default. For the "pure" HTTP service, it will be transparent but it > > would > > >> have two impacts: > > >> * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg > > >> doesn’t exist anymore) > > >> * users using WebContainer PaxWeb API instead of HTTP service won’t > > work > > >> 3. We consider that Pax Web as it is today is not flexible enough and > > too > > >> painful, and we start an even larger refactoring on Pax Web. > > >> > > >> The reason why I’m bringing this discussion on the mailing list: we > > really > > >> need a clear plan and release 4.3.0 (I would really love to release > > 4.3.0 > > >> mid July max, so we need a plan). > > >> > > >> Thoughts ? > > >> > > >> Regards > > >> JB > > > > >
