Hi, as being responsible for supporting more then one container for Pax-Web it's been unclear at the time if Jetty would always be the best idea. (which you now can see regarding the latest Servlet spec) That's why I added Tomcat and Guillaume added Undertow later on. So much for the Why multiple underlying containers.
Now regarding R6 compatibility: Pax Web does support a Whiteboard Approach since it's earliest stages: 0.6. It's been improved all those years from 1.0 till 4.x to match what was capable with the web-container approach. Then the Felix HTTP project created a "new" reference for the Whiteboard Specification (aka R6). When trying to adapt to it, it's always been a trade off between sticking to the already known implementation to the community and aligning with R6. That's why it's never been really R6 compliant, only close to. I know what a tremendous workload it is to refactor the whole stack to be R6 compliant. So big Kudos to Greg for taking this :) Unfortunately my dayjob has been consuming too much of my time to be of any help, and when I tried to help out a bit I realised the refactored version isn't what I was remembering. So I have to admit ... I won't be much of a help on the project anymore :( If you would ask me where to take a shortcut, I'd say, sorry no way. If we want it to be R6/7/8 compliant we'll need to go through that valley of tears to get to it. I just hope there are more people able to help Greg to get there. regards, Achim P.S. it really saddens me of not being able to help on this, anymore :( Am Di., 7. Juli 2020 um 14:17 Uhr schrieb Jean-Baptiste Onofre < j...@nanthrax.net>: > Hi, > > I will help you. The purpose is to have a viable ETA for Pax Web 8.0 (for > Karaf 4.3). > > Do you think reasonable to target end of next week fo Pax Web 8.0.0 (even > if all is not completed/fixed) if we work together ? > > That would be great. > > Regards > JB > > > Le 7 juil. 2020 à 12:23, Grzegorz Grzybek <gr.grzy...@gmail.com> a > écrit : > > > > 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 > >> > >> > > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
