Thanks very much Grzegorz for all the great work on pax-web! regards,
François [email protected] Le 07/07/2020 à 16:33, Grzegorz Grzybek a écrit : > Hello > > I'm proud to announce that I've pushed master-improvement changes where you > can simply call `mvn clean install` AND `mvn clean install -Pequinox`. > > Check for example pax-web-itest-undertow tests (see the times!) > > [INFO] ------------------------------------------------------- > [INFO] T E S T S > [INFO] ------------------------------------------------------- > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 3.458 s - in > org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest > [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 2.524 s - in > org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 2.747 s - in > org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest > [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 2.956 s - in > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest > [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 2.891 s - in > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest > [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 3.346 s - in > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest > [INFO] Running > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest > [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 2.832 s - in > org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest > > These are not all previous tests, but I'm moving them one at a time from > pax-web-itest-container-xxx to pax-web-itest-xxx (so I know what works and > what doesn't). > > With this push, I think I've covered a huge amount of missing unification > related to welcome file handling. Please feel free to play with the current > state of the branch. In the coming days, I'm going to add a cherry on top > of welcome file handling by adding a whiteboard layer to it. > > Whiteboard layer is all about tracking "incoming" services and turning them > into "models" (customization) - I've removed the intermediary layer of "web > elements" present in Pax Web 7. > > Kudoz to Achim and other Pax Web developers who created Pax Web Extender > Whiteboard before CMPN Whiteboard was crafted (and IT was inspired by Pax > Web, not vice versa!) > > The biggest problem I was thinking of when saying "Pax Web 7 was not R6 > Whiteboard compliant) is this OSGi filter: > > (osgi.http.whiteboard.servlet.name=*) > > stored in "osgi.http.whiteboard.context.select" service registration > property. Supporting it required deep refactoring, but I think it's already > done. > > Welcome file (and resource) handling in Pax Web 8 is changed, so it also > leverages as much as possible from: > - org.apache.catalina.servlets.DefaultServlet > - io.undertow.servlet.handlers.DefaultServlet > - org.eclipse.jetty.servlet.DefaultServlet > > So we have now (for free!) caching, etags and Accept-Ranges support. > > Handling URLs from HttpContext/ServletContextHelper.getResource() like > "bundle://22.0:1/" (Felix), bypassing > https://issues.apache.org/jira/browse/FELIX-6294, handling "bundle > directories", welcome files from file:/bundle:/bundleresource: URIs now > works consistently across runtimes. > > Here's rough plan for coming weeks: > - whiteboard layer for implemented resources/welcome files (2 days max) > - error page handling for implemented servlet registration (1 day max) > - pax-web-extender-war - I wanted to implement transactional web.xml > registration (begin() + end()) and it requires little design, but the "one > configuration thread" is created with this transactional approach in mind > - JSF resource lookup - I've spend lot of time to check all possible > resource fetching methods (bundle resources/entries, classloaders, > fragments, wirings, ...), so it's a matter of test migration and checking > where do we want "BundleResourceClassLoader" > - per-context session handling (felix.http has this), but I don't think we > need it for GA (per context attribute storage works already!) > - registration of ServletContainerInitializers and login configs - I > didn't look into it yet, but that fits perfectly into what we already have > - JSPs - lot of initial work (last year!) was done to handle JSPs better > (without duplicating/shading/private-packaging Jasper classes) - I already > have pax-web-itest-jsp project with exotic things like custom tag files > tests. pax-web-tomcat-common bundle was created to support pax-web-jsp with > better OSGi manifest. Also, JSP servlet with current servlet > (un)registration handling should not be a problem > > I really devote much of my daily job (and free time ;) for this, but I'm > 100% sure, that we're almost there - at least I don't expect bigger issues > (which wasn't true when I started the refactoring) > > kind regards > Grzegorz Grzybek > > wt., 7 lip 2020 o 16:11 Achim Nierbeck <[email protected]> > napisał(a): > >> 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 < >> [email protected]>: >> >>> 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 <[email protected]> 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 <[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 >>>>> >>> >> -- >> >> 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> >>
