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