Hello I can say only about Karaf 4.3.0. I'm indeed working on Pax Web 8 (I'm finally at the stage where I can actually push some (almost) atomic changes. Initially it was just 100+ files changed at once). Current state can be checked in master-improvements branch <https://github.com/ops4j/org.ops4j.pax.web/commits/master-improvements>.
I found just too many places in Pax Web 7 that were just too much against R6 specification and I needed ... more changes than I planned. Even if I've not reviewed yet pax-web-extender-war, I've rebuilt the foundation so seriously with both WAR and Whiteboard extenders in mind that it should be easier to progress now. The most important change in Pax Web 8 now is that there's clear distinction between "OSGi Context Model" and "Servlet Context Model". Here are some requirements that stem directly from specification and I've already implemented them: - "Servlet Context Model" is in 1:1 relation with actual servlet context (or single, unique "context path" like "/c1") - "OSGi Context Model" is in 1:1 relation with HttpContext (from Http Service spec) or ServletContextHelper (from Whiteboard Service spec). Such "OSGi context" "points to" single "Servlet Context" - *but* there may be many "OSGi Context Models" pointing to single "Servlet Context Model" - *also*, single Whiteboard-registered servlet may be associated with many "OSGi Context Models" The implications are sometimes amazing: - a servlet may be registered to many "OSGi Context Models", which point to different "Servlet Context Models" - this means servlet /s may be available under /c1/s and /c2/s - a servlet may be registered to many "OSGi Context Models", which point to *the same* "Servlet Context Models" - this means servlet /s may be available under /c/s but handleSecurity() is taken from "OSGi Context Model" with highest ranking - Pax Web 7 didn't do that at all - a filter may be mapped to /* and be associated with many "OSGi Context Models", but should be added to filter chain ONLY if the chain ends with a servlet associated with matching "OSGi Context Model" - a servlet associated wtih "OSGi Context Model" point to, say, /c1 "Servlet Context" is available at, say, /c1/s. But when service registration properties for the associated ServletContextHelper (1:1 with "OSGi Context Model") change, servlet has to "switch" from /c1/s to, say, /c2/s (or even /s when given "OSGi Context Model" starts being associated with the default "Servlet Context Model" So, you see (I hope) that Pax Web 8 is not going to be an easy release ;) But I really try hard now... regards Grzegorz Grzybek czw., 19 mar 2020 o 05:35 Jean-Baptiste Onofre <j...@nanthrax.net> napisał(a): > Hi everyone, > > First of all, I’m sorry for the ones who are on Slack, I have some > connection issues since yesterday morning. It should be fixed by the end of > today max. > > Anyway, I would like to move forward about the releases. > > For this week, I would like to submit to vote: > > - Decanter 2.3.0: it’s a major (very major ;)) release bringing new > features (new alerting service with much better condition, time series, > Prometheus appender, new collectors, …), updates (Elasticsearch 7 support, > …) and fixes. I’m rebasing and polishing branches, I hope to submit > Decanter release to vote during the week end. > - Karaf 4.2.9, even if it doesn’t contain as much as 4.2.8, I would like > to submit this release to vote as it contains the fix about HTTPs access to > Maven Central. As for Decanter, I plan the start the vote during the week > end or early next week. > - Karaf 4.3.0. We released 4.3.0.RC1 some weeks ago. Unfortunately we > didn’t get lot of feedback. So, even if Pax Web is not fully ready for OSGi > R7 (thanks again to Greg for working hard on this), I propose to move > forward on 4.3.0 "as it is". Thoughts ? > > Regards > JB
