Hello wt., 7 lip 2020 o 13:30 Serge Huber <shu...@jahia.com> napisał(a):
> Hi guys, > > Interesting discussion. I'd love to see Karaf 4.3 asap. > > As (mostly) a user of Pax Web, I'm wondering if just focusing on Jetty > instead of supporting both Jetty & Tomcat could make things faster and > maybe easier to integration test? I'm sure there are use cases for Tomcat > that I'm not aware of but I'm wondering what they are? > To be honest - supporting 3 instead of 1 container was always an advantage of Pax Web. Fortunately the maintenance cost doesn't rise by 200% :) And for example I personally use Karaf with Undertow. > > As a Karaf user, my biggest need is for a "global" interception mechanism > on the HTTP service to be able to build filters for security, CSRF, etc... > which are things that Pax Web doesn't support right now. > Global interception mechanism are supposed to be supported by "preprocessors" from Whiteboard R7 (per context), for Pax Web I've implemented a mechanism that allows this - see: https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing regards Grzegorz Grzybek > > Regards, > Serge... > > Serge Huber > CTO & Co-Founder > T +41 22 361 3424 > 9 route des Jeunes | 1227 Acacias | Switzerland > jahia.com <http://www.jahia.com/> > SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER > <https://twitter.com/sergehuber> | VCARD > <http://www.jahia.com/vcard/HuberSerge.vcf> > > > > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and > to discover why Jahia is a leading User Experience Platform (UXP) for > Digital Transformation. > > > On Tue, Jul 7, 2020 at 12:23 PM Grzegorz Grzybek <gr.grzy...@gmail.com> > wrote: > > > 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 > > > > > > > > >
