Re: State of Pax Web 8

[JB Onofré]

I second Matt and Serge. 

As discussed together yesterday it’s really great work ! Thanks !

Regards
JB

> Le 27 juil. 2021 à 14:07, Matt Pavlovich  a écrit :
> 
> Great work!  Thank you for all the effort you’ve put forth
> 
> On Jul 27, 2021, at 1:00 AM, Grzegorz Grzybek  wrote:
> 
> 
> Hello
> 
> I'd just like to let you know that everything is under control and I didn't 
> abandon the effort.
> 
> I've added a todo.txt file[1] to Pax Web's main branch (I didn't create 
> separate GH issues for the tasks yet, as the scope may change, but at some 
> point I'll translate the remaining items to GH issues).
> 
> So currently (and for some time already) I'm patiently making existing (Pax 
> Web 7) integration tests work with Pax Web 8.
> 
> The remaining integration tests cover (~10 tests):
> - HttpContext processing[2] (that's beyond CMPN specifications)
> - Whiteboard websockets (beyond CMPN specifications)
> - DTO tests
> - JAX-RS tests
> - Jetty/Tomcat/Undertow bundles tests
> - Jetty Handlers/Connectors OSGi services
> - VirtualHosts
> - CRLs
> - Jasypt
> 
> The already working (much faster due to better listeners!) tests include 
> (almost 200 per container runtime):
> - external jetty.xml/tomcat-server.xml/undertow.xml configuration
> - HttpService/WebContainer tests (CMPN chapter 102)
> - JSP tests (custom tags, directives, includes, ...)
> - WABs (including SCIs, WebSockets, scanning and fragments)
> - JSF
> - Vaadin (new!)
> - Whiteboard (much improved, including SCR and standard services)
> 
> The most important aspects of chapters 102 (Http Service), 128 (Web 
> Applications) and 140 (Whiteboard) are implemented including the most 
> important one - 1:N mapping between web elements and _contexts_.
> 
> The other most important aspect, not related to CMPN specifications is the 
> consistency of behavior between Jetty, Tomcat and Undertow containers - only 
> ONE integration test has container specific behavior - the test checking HTTP 
> response when POST size (container-specific configuration) is exceeded.
> 
> I roughly plan to release Pax Web 8 around mid of September.
> 
> kind regards
> Grzegorz Grzybek
> ===
> [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
> [2]: 
> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing
> 
> --
> --
> --
> OPS4J - http://www.ops4j.org - op...@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ops4j/CAAdXmhpg%3Dn_LizOosNYnt43MZh_01CNU%2BZ0zfPFF4a9JaaQOvQ%40mail.gmail.com.

Re: State of Pax Web 8

[Matt Pavlovich]

Great work!  Thank you for all the effort you’ve put forth

On Jul 27, 2021, at 1:00 AM, Grzegorz Grzybek  wrote:


Hello

I'd just like to let you know that everything is under control and I didn't 
abandon the effort.

I've added a todo.txt file[1] to Pax Web's main branch (I didn't create 
separate GH issues for the tasks yet, as the scope may change, but at some 
point I'll translate the remaining items to GH issues).

So currently (and for some time already) I'm patiently making existing (Pax Web 
7) integration tests work with Pax Web 8.

The remaining integration tests cover (~10 tests):
 - HttpContext processing[2] (that's beyond CMPN specifications)
 - Whiteboard websockets (beyond CMPN specifications)
 - DTO tests
 - JAX-RS tests
 - Jetty/Tomcat/Undertow bundles tests
 - Jetty Handlers/Connectors OSGi services
 - VirtualHosts
 - CRLs
 - Jasypt

The already working (much faster due to better listeners!) tests include 
(almost 200 per container runtime):
 - external jetty.xml/tomcat-server.xml/undertow.xml configuration
 - HttpService/WebContainer tests (CMPN chapter 102)
 - JSP tests (custom tags, directives, includes, ...)
 - WABs (including SCIs, WebSockets, scanning and fragments)
 - JSF
 - Vaadin (new!)
 - Whiteboard (much improved, including SCR and standard services)

The most important aspects of chapters 102 (Http Service), 128 (Web 
Applications) and 140 (Whiteboard) are implemented including the most important 
one - 1:N mapping between web elements and _contexts_.

The other most important aspect, not related to CMPN specifications is the 
consistency of behavior between Jetty, Tomcat and Undertow containers - only 
ONE integration test has container specific behavior - the test checking HTTP 
response when POST size (container-specific configuration) is exceeded.

I roughly plan to release Pax Web 8 around mid of September.

kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
[2]: 
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing

--
--
--
OPS4J - http://www.ops4j.org - op...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CAAdXmhpg%3Dn_LizOosNYnt43MZh_01CNU%2BZ0zfPFF4a9JaaQOvQ%40mail.gmail.com.

Re: State of Pax Web 8

[Serge Huber]

Thank you so much for all this work, I cannot tell you enough how much it
is appreciated!

I've programmed my share of web containers in the past and I know how
tricky this can be to get right.

Regards,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com 
SKYPE | LINKEDIN  | TWITTER
 | VCARD



> JOIN OUR COMMUNITY  to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Tue, Jul 27, 2021 at 8:09 AM  wrote:

> This is very nice and thank you very much Grzegorz for all your great
> work on Pax Web!
>
> regards,
>
> François
> fpa...@apache.org
>
> Le 27/07/2021 à 08:00, Grzegorz Grzybek a écrit :
> > Hello
> >
> > I'd just like to let you know that everything is under control and I
> didn't
> > abandon the effort.
> >
> > I've added a todo.txt file[1] to Pax Web's main branch (I didn't create
> > separate GH issues for the tasks yet, as the scope may change, but at
> some
> > point I'll translate the remaining items to GH issues).
> >
> > So currently (and for some time already) I'm patiently making existing
> (Pax
> > Web 7) integration tests work with Pax Web 8.
> >
> > The remaining integration tests cover (~10 tests):
> >  - HttpContext processing[2] (that's beyond CMPN specifications)
> >  - Whiteboard websockets (beyond CMPN specifications)
> >  - DTO tests
> >  - JAX-RS tests
> >  - Jetty/Tomcat/Undertow bundles tests
> >  - Jetty Handlers/Connectors OSGi services
> >  - VirtualHosts
> >  - CRLs
> >  - Jasypt
> >
> > The already working (much faster due to better listeners!) tests include
> > (almost 200 per container runtime):
> >  - external jetty.xml/tomcat-server.xml/undertow.xml configuration
> >  - HttpService/WebContainer tests (CMPN chapter 102)
> >  - JSP tests (custom tags, directives, includes, ...)
> >  - WABs (including SCIs, WebSockets, scanning and fragments)
> >  - JSF
> >  - Vaadin (new!)
> >  - Whiteboard (much improved, including SCR and standard services)
> >
> > The most important aspects of chapters 102 (Http Service), 128 (Web
> > Applications) and 140 (Whiteboard) are implemented including the most
> > important one - 1:N mapping between web elements and _contexts_.
> >
> > The other most important aspect, not related to CMPN specifications is
> the
> > consistency of behavior between Jetty, Tomcat and Undertow containers -
> > only ONE integration test has container specific behavior - the test
> > checking HTTP response when POST size (container-specific configuration)
> is
> > exceeded.
> >
> > I roughly plan to release Pax Web 8 around mid of September.
> >
> > kind regards
> > Grzegorz Grzybek
> > ===
> > [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
> > [2]:
> >
> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing
> >
>

Re: State of Pax Web 8

[fpapon]

This is very nice and thank you very much Grzegorz for all your great
work on Pax Web!

regards,

François
fpa...@apache.org

Le 27/07/2021 à 08:00, Grzegorz Grzybek a écrit :
> Hello
>
> I'd just like to let you know that everything is under control and I didn't
> abandon the effort.
>
> I've added a todo.txt file[1] to Pax Web's main branch (I didn't create
> separate GH issues for the tasks yet, as the scope may change, but at some
> point I'll translate the remaining items to GH issues).
>
> So currently (and for some time already) I'm patiently making existing (Pax
> Web 7) integration tests work with Pax Web 8.
>
> The remaining integration tests cover (~10 tests):
>  - HttpContext processing[2] (that's beyond CMPN specifications)
>  - Whiteboard websockets (beyond CMPN specifications)
>  - DTO tests
>  - JAX-RS tests
>  - Jetty/Tomcat/Undertow bundles tests
>  - Jetty Handlers/Connectors OSGi services
>  - VirtualHosts
>  - CRLs
>  - Jasypt
>
> The already working (much faster due to better listeners!) tests include
> (almost 200 per container runtime):
>  - external jetty.xml/tomcat-server.xml/undertow.xml configuration
>  - HttpService/WebContainer tests (CMPN chapter 102)
>  - JSP tests (custom tags, directives, includes, ...)
>  - WABs (including SCIs, WebSockets, scanning and fragments)
>  - JSF
>  - Vaadin (new!)
>  - Whiteboard (much improved, including SCR and standard services)
>
> The most important aspects of chapters 102 (Http Service), 128 (Web
> Applications) and 140 (Whiteboard) are implemented including the most
> important one - 1:N mapping between web elements and _contexts_.
>
> The other most important aspect, not related to CMPN specifications is the
> consistency of behavior between Jetty, Tomcat and Undertow containers -
> only ONE integration test has container specific behavior - the test
> checking HTTP response when POST size (container-specific configuration) is
> exceeded.
>
> I roughly plan to release Pax Web 8 around mid of September.
>
> kind regards
> Grzegorz Grzybek
> ===
> [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
> [2]:
> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing
>

State of Pax Web 8

[Grzegorz Grzybek]

Hello

I'd just like to let you know that everything is under control and I didn't
abandon the effort.

I've added a todo.txt file[1] to Pax Web's main branch (I didn't create
separate GH issues for the tasks yet, as the scope may change, but at some
point I'll translate the remaining items to GH issues).

So currently (and for some time already) I'm patiently making existing (Pax
Web 7) integration tests work with Pax Web 8.

The remaining integration tests cover (~10 tests):
 - HttpContext processing[2] (that's beyond CMPN specifications)
 - Whiteboard websockets (beyond CMPN specifications)
 - DTO tests
 - JAX-RS tests
 - Jetty/Tomcat/Undertow bundles tests
 - Jetty Handlers/Connectors OSGi services
 - VirtualHosts
 - CRLs
 - Jasypt

The already working (much faster due to better listeners!) tests include
(almost 200 per container runtime):
 - external jetty.xml/tomcat-server.xml/undertow.xml configuration
 - HttpService/WebContainer tests (CMPN chapter 102)
 - JSP tests (custom tags, directives, includes, ...)
 - WABs (including SCIs, WebSockets, scanning and fragments)
 - JSF
 - Vaadin (new!)
 - Whiteboard (much improved, including SCR and standard services)

The most important aspects of chapters 102 (Http Service), 128 (Web
Applications) and 140 (Whiteboard) are implemented including the most
important one - 1:N mapping between web elements and _contexts_.

The other most important aspect, not related to CMPN specifications is the
consistency of behavior between Jetty, Tomcat and Undertow containers -
only ONE integration test has container specific behavior - the test
checking HTTP response when POST size (container-specific configuration) is
exceeded.

I roughly plan to release Pax Web 8 around mid of September.

kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
[2]:
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing

Re: [PAX WEB] State of Pax Web 8

[Grzegorz Grzybek]

Hello

Actually it is a good time to give you a hint about the new "context"
organization in Pax Web. I'll try to be concise.

Fundamentally a "context" is a container-specific implementation of
javax.servlet.ServletContext and maps 1:1 with a "context path" ("/",
"/my-context" or any name that stems from the WAR base name you drop to
Tomcat/Jetty/Wildfly/...).

In OSGi CMPN Whiteboard Service spec, a "context" is represented by a name
referring to some (possibly default) implementation of
org.osgi.service.http.context.ServletContextHelper.
In OSGi CMPN Http Service spec, a "context" is the object (default if null)
you pass to HttpService.registerServlet(..., httpContext), but in Pax Web,
internally it is treated (after some adjustments) as ServletContextHelper.

Because according to Whiteboard specification,
org.osgi.service.http.context.ServletContextHelper may be
whiteboard-registered as OSGi service, it has to be "customized" by some
service tracker - so Pax Web 8 has something called
org.ops4j.pax.web.service.spi.model.OsgiContextModel. This is an object
used to represent org.osgi.service.http.HttpContext and
org.osgi.service.http.context.ServletContextHelper internally.

There are FOUR trackers that take incoming service and customize it to
org.ops4j.pax.web.service.spi.model.OsgiContextModel (names should given
you a hint about "incoming" object):
 -
org.ops4j.pax.web.extender.whiteboard.internal.tracker.legacy.HttpContextMappingTracker
("legacy" Pax Web Whiteboard)
 -
org.ops4j.pax.web.extender.whiteboard.internal.tracker.HttpContextTracker
(Pax Web Whiteboard to track objects not designed (by the spec) to be
registered as services)
 -
org.ops4j.pax.web.extender.whiteboard.internal.tracker.legacy.ServletContextHelperMappingTracker
("legacy" Pax Web Whiteboard for standard ServletContextHelper)
 -
org.ops4j.pax.web.extender.whiteboard.internal.tracker.ServletContextHelperTracker
(THE tracker to track standard Whiteboard
org.osgi.service.http.context.ServletContextHelper servlces)

So all the web elements (servlets, filters, listeners, error pages, welcome
files, ...) are registered "in association" with one OR MORE (and this
"more" is something that was fundamentally missing in Pax Web 7)
org.ops4j.pax.web.service.spi.model.OsgiContextModel.

Now the connection with Jetty/Tomcat/Undertow. Because user may register
many ServletContextHelper services with different (or same) value for
"osgi.http.whiteboard.context.path" service property, we may have this tree
of related objects:

Jetty/Tomcat/Undertow implementation of javax.servlet.ServletContext for
"/" context path
|
+-- org.ops4j.pax.web.service.spi.model.OsgiContextModel 1a
+-- org.ops4j.pax.web.service.spi.model.OsgiContextModel 2a with a bit
lower ranking
+-- ...

Jetty/Tomcat/Undertow implementation of javax.servlet.ServletContext for
"/some" context path
|
+-- org.ops4j.pax.web.service.spi.model.OsgiContextModel 1b
+-- org.ops4j.pax.web.service.spi.model.OsgiContextModel 2b with a bit
lower ranking
+-- ...

Of course of you simply modify a registration of already registered
ServletContextHelper (customized by trackers into OsgiContextModel by
changing its ranking, the above relations may change and different
OsgiContextModel will be "effective" for given container-specific context.

Of course you can imagine that you change not the ranking but
"osgi.http.whiteboard.context.path" property (say from "/" to "/path") -
this can (should, according to Whiteboard spec) re-register already
registered servlets, so they may "switch" from being mapped under
"/servlet-mapping" to being mapped under "/path/servlet-mapping"... That's
already implemented ;)

Also, according to "140.2.7 Relation to the Servlet Container", servlets
(and filters) should see such "ServletContext" that when they call
"getResource()" on it, they'll get (by default) resources from the bundle
that registered given context (nothing similar to such behavior in Pax Web
7). Also we can have many servlets registered to the same "context", but
using different bundles - they should NOT be able to "getResource()" from a
wrong bundle!

Finally org.ops4j.pax.web.service.spi.servlet.OsgiServletContext IS an
implementation of javax.servlet.ServletContext that does exactly this -
wrap actual container-specific ServletContext and implement some methods
according to Whiteboard spec.

Of course "addServlet()" throws (in Whiteboard specification)
UnsupportedOperationException.

But fortunately I have all the pieces ready to properly (despite the
specification) register a servlet/filter/listener from
ServletContainerInitializer - EXACTLY as if they were registered through
Whiteboard (with validation and default service ranking) - so existing
mechanisms will be used - such servlets can easily be wrapped with
Whiteboard filters and will integrate with what I've already refactored.

So please give me a little more time! I don't want to sacrifice great work
others already did (Achim, Mark, Guillaume, JB

Fwd: [PAX WEB] State of Pax Web 8

[Grzegorz Grzybek]

Hello

If you look at the attached table, you'll see what's already implemented
and what yet has to be done. From Whiteboard point of view, I'm almost
there, because These are already tracked:
 - servlets
 - filters
 - listeners
 - resources (which are internally servlets)
 - contexts (ServletContextHelper)
 - error pages (as registration parameters of servlets)

As you know, the strength of Pax Web is that it tracks more. These are
implemented:
 - welcome files (whew - that was tricky - OSGi CMPN Whiteboard spec
doesn't make it easy to implement it)
 - error pages (as separate objects)

Also, WebContainer (an extension of org.osgi.service.http.HttpService) also
allows to register additional "web elements" and I'm in the process of
implementing everything that's mentioned in the table.

However, I've just found a really nasty obstacle... See 140.2.6 Behavior of
the Servlet Context

:

addServlet(...) | 3.0 | Throws UnsupportedOperationException.

OSGi CMPN Whiteboard spec:
 - didn't care about the dynamism and dynamic registration of
Servlets/Filters/Listeners
 - didn't care about something like
javax.servlet.ServletContainerInitializer (and JSPs, which are a bit
related in terms of their configuration).
 - has very strict (and already carefully implemented) separation of
"physical ServletContexts" from "OSGi ServletContexts". See "140.2 The
Servlet Context":

In the case of two Servlet Context Helpers with the same path, the service
with the highest ranking is searched first for a match. In the case of a
tie, the lowest service ID is searched first.

So - each registered ServletContextHelper should actually be implemented as
a separate ServletContext which delegates to a single (by contextPath)
container-specific ServletContext. It's about attribute separation, session
separation, classloader separation and security handling. I spent most of
my refactoring to implement this behavior correctly and it's presented in
"140.2.7 Relation to the Servlet Container":

[image: image.png]

So, what's the problem? If some ServletContainerInitializer (like
org.apache.myfaces.ee6.MyFacesContainerInitializer) is used (it works now
in Pax Web 7, because Pax Web 7 doesn't do the above delegation), it calls:

// the FacesServlet is not installed yet - install it
ServletRegistration.Dynamic servlet =
servletContext.addServlet(FACES_SERVLET_NAME, FACES_SERVLET_CLASS);

And according to OSGi CMPN Whiteboard spec, it should simply throw
UnsupportedOperationException (bye, bye TCK compliance).

I of course don't care much about such flaws in specification and I really
want to implement this (allow JSF to work in Pax Web 8). But I have to
spend a bit more time with dynamic registration of servlets and filters -
especially because current HttpService/WebContainer/Whiteboard registration
is already working great (with all the service ranking shadowing).

In other words - a servlet registered by some 3rd party customizer, should
integrate well with what we already have. It should be able to shadow such
servlet (by registering one with higher ranking and same name/patterns), it
should be able to register a filter to it (or a preprocessor), it should
(?) be possible visible through HttpRuntime service (DTOs).

This problem was revealed when I was bringing back JSP support (which again
is not covered by OSGi CMPN). So I have to work on it more (support is
always welcomed!).

We could also think about releasing Pax Web 8 with ready (it really is!)
implementation of R7 Whiteboard spec only, but this would be a much trimmed
down version of the Pax Web we know...

Here's the current state of implementation (sorry if it formats badly).
"no" means it is not and will not be implemented. Empty cell means the
implementation is still in progress.

[image: image.png]

best regards
Grzegorz Grzybek