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 <https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e119708> : 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
