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

2020-02-03 Thread 'Achim Nierbeck' via OPS4J
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


Am Mo., 3. Feb. 2020 um 13:00 Uhr schrieb Jean-Baptiste Onofré <
jeanbaptiste.ono...@gmail.com>:

> 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 - ops4j@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/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.com
> 
> .
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@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/196d3c36-65b2-13d2-6c44-8c2ea0d24fd7%40gmail.com
> 
> .
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAD0r13e0ma_KiCac0m-_bJPm5jpniBayCtXUOYhmcFNjA_W6XA%40mail.gmail.com.


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

2020-02-03 Thread 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

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 - ops4j@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/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.com
> .

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/196d3c36-65b2-13d2-6c44-8c2ea0d24fd7%40gmail.com.


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

2020-02-03 Thread 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

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@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/CAAdXmhqXXt3USsZ14HFFEGz3vY7rU5zEgU5XrmEjWoMTd00TEg%40mail.gmail.com.