Hello
pt., 29 kwi 2022 o 16:38 Alain Picard <[email protected]> napisał(a): > Hi Grzegorz, > > I see the Keycloak issue and what is mentioned there. What does that mean > for KC integration going forward ? > Keycloak team decided to remove the "Fuse adapters". Because indeed - these, even if using Pax Web extension mechanism (ServiceLoader of /META-INF/services/org.ops4j.pax.web.service.AuthenticatorService), they were created (and worked only on Undertow side), were created for JBoss/RedHat Fuse integration. Even the location of these adapters in Keycloak source tree ( https://github.com/keycloak/keycloak/tree/18.0.0/adapters/oidc/fuse7) suggest "Fuse" as the target platform, while there's nothing beyond Pax Web here. I see kind of opportunity here and the integration parts: - bundle fragments with /META-INF/services/org.ops4j.pax.web.service.AuthenticatorService - Karaf features can be moved from Keycloak into Pax Web itself. I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1716 to track this idea. kind regards Grzegorz Grzybek > > Alain > > On Friday, April 29, 2022 at 5:36:48 AM UTC-4 [email protected] wrote: > >> Hello >> >> I'm planning to release Pax Web 8.0.3 with 6 issues fixed, including: >> >> - Keycloak integration tweaks (see >> https://issues.redhat.com/browse/KEYCLOAK-19939) >> - refined session management (session per Osgi Context with single >> JSESSIONID cookie per Servlet Context) >> - two deadlocks fixes (Aries CDI) >> - gzip encoding configuration and Jetty RewriteHandler support >> >> With the above fixes, *I think my long term plan to refactor Pax Web >> ends*. It doesn't mean I quit, it simply means I don't plan anything new >> to add to Pax Web if there's no request to do so. >> >> IMO, the compliance with chapters 102 (Http Service), 128 (Web >> Applications) and 140 (Whiteboard Service) of OSGi CMPN specification (R7, >> but should be the same for R8) is sufficiently complete. I didn't run the >> TCKs, because I didn't have much time to understand how to run it in proper >> way ;) >> >> There's one obvious violation of Whiteboard specification wrt to context >> handling. See 140.2 The Servlet Context >> <https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext> >> [1]: >> >> For example, if two ServletContextHelper services are registered as >>> follows >>> >>> osgi.http.whiteboard.context.path = /foo >>> osgi.http.whiteboard.context.path = /foo/bar >>> >>> Then a request for http://localhost/foo/bar/someServlet is looked up in >>> the following order: >>> >>> 1. /foo/bar context looking for a pattern to match /someServlet >>> 2. /foo context looking for a pattern to match /bar/someServlet >>> >>> According to JavaServlet specification, context selection happens first >> and further resolution of servlets is performed within the found context. >> The above Whiteboard requirement mandates searching for servlets in other >> contexts. I've consciously NOT implemented the Whiteboard behavior, >> sticking to JavaServlet recommendation. >> >> Anyway - I hope Pax Web 8 is stable and fast enough to be used in >> production. There are much more tests than we had in Pax Web 7 and I've >> added complex WAR scenarios involving CDI, JSF and complex >> ServletContainerInitializer scenarios, including web-fragment.xml >> integration tests. >> >> I'll of course be releasing new versions if there's new Jetty, Tomcat or >> Undertow release - in Pax Web 8 we no longer require TIPI releases for >> Tomcat. >> >> If you see any problems or have nice feature requests, please create a >> GitHub issue at usual place >> <https://github.com/ops4j/org.ops4j.pax.web/issues>[2]. >> >> kind regards >> Grzegorz Grzybek >> === >> [1]: >> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext >> [2]: https://github.com/ops4j/org.ops4j.pax.web/issues >> > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/bc9d65ff-ed7a-4d26-b8ca-80240efe666fn%40googlegroups.com > <https://groups.google.com/d/msgid/ops4j/bc9d65ff-ed7a-4d26-b8ca-80240efe666fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhrJH_VzC-cBy2T6U9DY8U9H7bfffGdOzk6ynEXbMmN-KQ%40mail.gmail.com.
