You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Grzegorz Grzybek <gr...@gmail.com> on 2022/04/29 09:36:29 UTC
The state of Pax Web
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
Re: The state of Pax Web
Posted by Grzegorz Grzybek <gr...@gmail.com>.
pt., 29 kwi 2022 o 16:44 Matt Pavlovich <ma...@hyte.io> napisał(a):
> Hi Grzegorz-
>
>
>
> Great work on this refactor, it was quite an undertaking! Saying “much
> appreciated” seems like not enough =).
>
It was my pleasure - another reason to admire internal OSGi design :) I had
really good time working with the code written greatly by others. I hope my
goal to only polish things and to make them more stable and spec compliant
as achieved - not many classes were removed. And not many were added.
I hoped to make things work as similar as possible between Jetty, Tomcat
and Undertow and I think the structure of pax-web-jetty, pax-web-tomcat and
pax-web-undertow is really similar, so anyone can work on it without
getting lost ;)
>
>
> We have a JMeter test suite that we’ll run against Karaf + Pax Web v8.0.3
> and report back in the few couple weeks for functionality and performance
> —covers REST and Web app servlet functionality.
>
Great! I'd love to see the results!
regards
Grzegorz Grzybek
>
>
> Thank you,
>
> Matt Pavlovich
>
>
>
> *From: *ops4j@googlegroups.com <op...@googlegroups.com> on behalf of
> Grzegorz Grzybek <gr...@gmail.com>
> *Date: *Friday, April 29, 2022 at 4:36 AM
> *To: *OPS4J <op...@googlegroups.com>, Karaf Dev <de...@karaf.apache.org>
> *Subject: *The state of Pax Web
>
> 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 - ops4j@googlegroups.com
>
> ---
> 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 ops4j+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> 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 ops4j+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/SN1PR12MB257338C2C1B8B0AA5B78CF9080FC9%40SN1PR12MB2573.namprd12.prod.outlook.com
> <https://groups.google.com/d/msgid/ops4j/SN1PR12MB257338C2C1B8B0AA5B78CF9080FC9%40SN1PR12MB2573.namprd12.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>
Re: The state of Pax Web
Posted by Matt Pavlovich <ma...@hyte.io>.
Hi Grzegorz-
Great work on this refactor, it was quite an undertaking! Saying “much appreciated” seems like not enough =).
We have a JMeter test suite that we’ll run against Karaf + Pax Web v8.0.3 and report back in the few couple weeks for functionality and performance —covers REST and Web app servlet functionality.
Thank you,
Matt Pavlovich
From: ops4j@googlegroups.com <op...@googlegroups.com> on behalf of Grzegorz Grzybek <gr...@gmail.com>
Date: Friday, April 29, 2022 at 4:36 AM
To: OPS4J <op...@googlegroups.com>, Karaf Dev <de...@karaf.apache.org>
Subject: The state of Pax Web
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 - ops4j@googlegroups.com
---
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 ops4j+unsubscribe@googlegroups.com<ma...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com<https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com?utm_medium=email&utm_source=footer>.