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 <bcanh...@googlemail.com.invalid> 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 < > 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> >
