[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] http servlet > 2.1 support

BJ wrote:
> I think it is not really worth the effort to attempt to 
> retrofit HttpService for newer Servlet API versions. You 
> would have to either implement the full Servlet spec 
> (including context path, filters, etc.) or tell the servlet 
> programmer which subset of the API you support. The former is 
> a lot of work and probably an awkward design; the latter sort 
> of defeats the purpose of trying to support existing servlets.

Thanks for the feedback. 
The HttpService definitely would need some work to bring it up to a
level of semi-compliance with the Servlet 2.4 API for exactly the
reasons you list.

For good or bad I've been working with the HttpServiece as currently
specified on top of a Servlet 2.4 implementation. I'd like to share my
experience in the hope of either deciding the HttpService is just fine
as is or potentially on devising a better way to support Servlets.

For the most part I've found the HttpService very workable and well
thought out. I've been able to run a wide variety of different Servlet
based solutions succesfully however on occasion I have encountered some
problems and I'll try to describe them here.

I've had some minor problems in that there is no direct "name" support
for Servlets or ServletContexts in the OSGi HttpService. The various get
name methods can return null (or a reasonable default) so the problem is
not show-stopping. I haven't personally run into it but the lack of name
support would be very problematic for users of
ServletContext.getNamedDispatcher(...) as well as
ServletContext.getContext(...).

The only incompatability I've run into that's caused any real grief is
with ServletContext.getResourcePaths(...). You can validly return null
for this method implying no resources found at the path however in
practice quite a few Servlets require the call to work correctly. The
HttpServices's "org.osgi.service.http.HttpContext" only has a
getResource method, but if it had a getResourcePaths(...) method I think
this problem would be largely resolved. Implementing getResourcePaths is
generally not very difficult however without direct support in the
HttpService API the solution is obviously proprietary.


So... one approach might be to tell the servlet programmer to avoid:
1) servlet/servletcontext "names" and
ServletContext.getNamedDispatcher(...)
2) ServletContext.getResourcePaths(...)
(I'm sure there are others issues but these two are a start)

Even with these restrictions I think a 2.4 version of the HttpService is
valuable. I've found that integration with many of the existing Web
Frameworks requires it. It also might be worthwhile to provide
extensions to the HttpService to handle these two problems in an
implementation. (?)

--

I've left out any discussion of context path and filters...
Filters might be addressable with a new version of the HttpService with
a "registerFilter" analagous to "registerServlet" added.
Context paths are tougher, and perhaps something like the WebContainer
specification you referred to is better suited to handle it.
Similarily, the various listeners might also be best handled in a
WebContainer specification.

-Simon 
  
       This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you.