[PAX WEB] 10 ways (in one of several categories) to register a servlet

[Grzegorz Grzybek]

Hello

I'm reviewing the consistency, stability and user-friendliness of Pax Web 8 and I tell myself that if now is not the good time to review the interfaces, then we'll never do it.

So, `org.ops4j.pax.web.service.WebContainer` (extension of `org.osgi.service.http.HttpService`) allows a servlet to be registered in ten (10) ways with different combination of these registration parameters:

 - alias

 - servlet (instance)

 - servlet class

 - servlet name

 - url patterns

 - init params

 - load-on-startup (flag)

 - async (flag)

 - multipartConfig (class from javax.servlet API 3+)

 - http context (org.osgi.service.http.HttpContext)

(so again, magic "10")

Additionally, users may:

 - register org.ops4j.pax.web.service.whiteboard.ServletMapping service that specifies 9 out of 10 of the above parameters directly in object's fields

 - register javax.servlet.Servlet service, where 5 parameters may be specified inside service registration dictionary (some Pax Web specific and 4 from OSGi CMPN Whiteboard specification)

 - some parameters may be discovered from annotations on registered service's class

None of WebContainer.registerServlet(...) methods accept ServletMapping directly. In both cases (user registers ServletMapping and user registers Servlet with service properties), relevant trackers eventually call org.ops4j.pax.web.service.WebContainer#registerServlet() with 8 out of 10 parameters (alias is just one of the patterns):

 - javax.servlet.Servlet

 - java.lang.String name

 - java.lang.String[] urlPatterns

 - java.util.Dictionary initParams

 - java.lang.Integer loadOnStartup

 - java.lang.Boolean asyncSupported

 - javax.servlet.MultipartConfigElement

 - org.osgi.service.http.HttpContext

It may be a bit confusing... And there are org.ops4j.pax.web.service.whiteboard.WhiteboardXXX interfaces (for DTO purposes)

We could remove all the variants entirely and leave method that simply accept org.ops4j.pax.web.service.whiteboard.ServletMapping (because it's now part of the API anyway) that could be created in builder-like way.

Or we could @Deprecate the variants...

I don't want to start revolution, I just want to ensure everything is consistent.

regards

Grzegorz Grzybek

[Jean-Baptiste Onofré]

Hi,

I think a cleanup is required.

For Pax Web 8.x, I would simply go with removing the discussed items.

Regards
JB

--
--
------------------
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.com.

[Achim Nierbeck]

Hi,

remove as much as you can, which doesn't leave it crippled.

As now we do have a good Whiteboard API by the osgi spec, we should try to stick to just that one, unless it's missing something.

The internal APIs to register Servlets might still be needed, but should be ok to be stripped down to the minimum requirements.

As far as I can remember, I was forced to keep a bunch of methods for backward compatibility.

regards, Achim

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/196d3c36-65b2-13d2-6c44-8c2ea0d24fd7%40gmail.com.

--

Apache Member

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

[Grzegorz Grzybek]

Hello

Thanks Achim for answer! Reply inline.

pon., 3 lut 2020 o 17:15 'Achim Nierbeck' via OPS4J <op...@googlegroups.com> napisał(a):

Hi,

remove as much as you can, which doesn't leave it crippled.

As now we do have a good Whiteboard API by the osgi spec, we should try to stick to just that one, unless it's missing something.

For whiteboard spec (OSGi CMPN R7, chapter 140) there's actually no API like with Http Service... There's ServletContextHelper, there's Filter specialization (Preprocessor), there are many annotations and properties but no real API.

There are some specification fragments that are fundamentally different than what we have in Pax Web:

140.2.6 Behavior of the Servlet Context

getClassLoader() - [...] Returns the class loader of the bundle that registered the Whiteboard service. An implementation of this specification can achieve this by returning separate façades of the ServletContext to each Whiteboard service. Each façade accesses the Whiteboard service's Bundle Wiring to obtain its class loader.

Currently servlets registered (through ServerController and Pax Web server abstraction) have their ServletContext mostly implementation-specific. We have pax-web-jetty's org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.SContext, pax-web-tomcat's org.ops4j.pax.web.service.tomcat.internal.HttpServiceContext.ServletApplicationContext, but no Undertow specific context. and neither of them implement javax.servlet.ServletContext#getClassLoader() to return proper class loader. Some methods are delegated to associated org.osgi.service.http.HttpContext though...

140.3 Common Whiteboard Properties

osgi.http.whiteboard.context.select - [...] To select all Servlet Context Helpers provide the following value: (osgi.http.whiteboard.context.name=*)

Which means we can register single servlet (with recommended prototype scope) in more than one servlet context or rather ServletContextHelper instance attached to javax.servlet.ServletContext. Currently Pax Web doesn't allow that and I don't see a one-line solution of this problem.

140.10 Integration with Http Service Contexts

A Http Whiteboard service which should be registered with a Http Context from the Http Service can achieve this by targeting a ServletContextHelper with the registration property osgi.http.whiteboard.context.httpservice. [...] This specification does not provide a way to select in individual Http Context from the Http Service, however a Http Whiteboard implementation may provide an implementation-specific mechanism to do this. [...] Association with Http Context from the Http Service can only be done for servlet filters, error pages and listeners. Servlets and resources cannot be associated with Http Contexts managed by the Http Service. If this is attempted this will be reflected in the failure DTOs.

The above is both confusing and irrational - why shouldn't I be able to register servlets through Http Service AND Whiteboard in the same context?

anyway - I'm still working on it.

regards

Grzegorz Grzybek

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAD0r13e0ma_KiCac0m-_bJPm5jpniBayCtXUOYhmcFNjA_W6XA%40mail.gmail.com.