Hello Thanks Achim for answer! Reply inline.
pon., 3 lut 2020 o 17:15 'Achim Nierbeck' via OPS4J <[email protected]> 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 > 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 > > > Am Mo., 3. Feb. 2020 um 13:00 Uhr schrieb Jean-Baptiste Onofré < > [email protected]>: > >> Hi, >> >> I think a cleanup is required. >> >> For Pax Web 8.x, I would simply go with removing the discussed items. >> >> Regards >> JB >> On 03/02/2020 11:54, Grzegorz Grzybek wrote: >> >> 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 >> -- >> -- >> ------------------ >> 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/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.com >> <https://groups.google.com/d/msgid/ops4j/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.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/196d3c36-65b2-13d2-6c44-8c2ea0d24fd7%40gmail.com >> <https://groups.google.com/d/msgid/ops4j/196d3c36-65b2-13d2-6c44-8c2ea0d24fd7%40gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > 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> > > -- > -- > ------------------ > 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/CAD0r13e0ma_KiCac0m-_bJPm5jpniBayCtXUOYhmcFNjA_W6XA%40mail.gmail.com > <https://groups.google.com/d/msgid/ops4j/CAD0r13e0ma_KiCac0m-_bJPm5jpniBayCtXUOYhmcFNjA_W6XA%40mail.gmail.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/CAAdXmhqDuYob%2B9GG6G5guYQ7AHW%3DSLSMizz-Ub0NcPXYA1UnXA%40mail.gmail.com.
