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] > <mailto:[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.
