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

equinox-dev-bounces@xxxxxxxxxxx wrote on 2005-11-22 01:11:03 PM:

> > There are issues with the HttpService design that cannot 
> > properly deal with Servlet API above 2.1. 
> 
> That's been my experience too; You get what the HttpService offers and
> no more.
> As you mention there is a one context per HttpService limitation and JSP
> support isn't there out of the box.
> Other things I miss include filters and the various session and
> servletcontext lifecycle listeners.
> 
> I'd be interested in helping bring the contributed HttpService
> implementation up to the Servlet 2.4 level for those portions exposed in
> the existing Http Service spec. My main concern is that we have an
> HttpService implementation that can run Servlets built with later
> versions of the Servlet API. I wonder how tough this would be?
> 
> I'd also be interested in doing work to support JSP within the bounds of
> the existing HttpService spec (perhaps through a proxy servlet or some
> other approach). I suspect this might be a fair sized job in that both
> compilation and runtime exposure would be tricky and might require
> framework support but still might be worthwhile. Any thoughts on how
> hard this might be?

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.

> 
> > IBM proposed a design to replace HttpService with a 
> > WebContainer specification for OSGi that supports JSPs and 
> > Servlet 2.3. This design was not incorporated into R4 by 
> > OSGi, but may make a future release. This design realized the 
> > limitations of the current HttpService design with respect to 
> > Servlet API beyond 2.1.
> 
> Sounds very interesting. Can you say more on this. Are there any
> implementation plans for it?
> 


IBM has an implementation of such a WebContainer in its OSGi offerings 
today (and has for some time) which include Servlet 2.3 and JSP 1.2 
support. We used the design for this as the basis for our design 
submission to OSGi. The IBM WebContainer works with R3 (with a few hoops 
jumped through) while the design proposal submitted to OSGi takes 
advantage of some new R4 framework features and Declarative Services to 
vastly simplify the WAB (Web Application Bundle) design. The IBM OSGi 
tools also include a WAB tool which converts a WAR file into a bundle 
(including precompilation of JSPs into servlets).

The one gap/issue in the WebContainer design is in the precompilation of 
JSPs into servlets. The JSP spec leaves several details regarding compiled 
JSPs up to the container implementation. This means that precompiled JSPs 
are bound to a specific container implementation unless OSGi chooses to 
specify these details to ensure tool/container interoperation. The current 
OSGi WebContainer design proposal is mute on these details. How important 
is it to decouple the precompiled JSPs from the WebContainer 
implementation? Specing these details will somewhat constrain a container 
implementation's JSP support.

> -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. 
> 
> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev


BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788