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 <[email protected]> napisał(a): > Hi, > > See my comment inline > > > Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <[email protected]> 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 <[email protected]> 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 > >
