[jetty-discuss] Re: Jetty 6 dependency on servlet API

[Jerome <gma...@no...>]

Greg,

I can see how the current design optimizes the handling of requests and 
responses because you can probably use the same object instance during 
all the request/response cycle: that's great.

However, as the dependency on the Servlet API is totally unnecessary in 
my case, I feel really bad about it. I would love to be able to ship a 
light Jetty HTTP server with the minimal set of classes required to 
implement the HTTP protocol (including thread management).

Please have a look at my project at http://www.restlet.org and 
especially at the introduction paper. You'll see why I care about a 
clean integration with Jetty. Also look at the 
org.restlet.data.Representation interface which is very close to the 
concept of contentlet that you proposed in one of your blog post.

Maybe there could be an intermediary approach, where Jetty would define 
two interfaces like:

HttpRequest
  - clientAddress : String		// client IP address
  - arrivalTime : long 			// request arrival time
  - methodName : String			// HTTP method name
  - requestURI : String			// URI including the host
  - headers : Map<String, String>	// HTTP headers
  - input : Contentlet  			// Request entity

HttpResponse
  - status : int				// HTTP status code
  - reasonPhrase : String 		// HTTP reason phrase
  - headers : Map<String, String>	// HTTP headers
  - output : Contentlet			// Response entity

Finally, a factory would be available to plug the concrete 
implementation of these interfaces. The we could easily provide multiple 
implementations:

1) Implementation for servlet engines:
  - One class could implements both the HttpRequest and 
HttpServletRequest interfaces, maybe setting the properties in the 
constructor
  - Another class could implements both the HttpResponse and 
HttpServletResponse interfaces

2) Implementation for restlet engines:
  - One class could implements both the HttpRequest, the HttpResponse 
and the UniformCall interfaces. Note that full non-blocking NIO support 
could be supported, including direct transfer from static files to 
result socket channels!

3) Implementation for Jetty 5 handlers, for compatibility purpose with 
applications only relying on theses handlers.

I hope that makes sense and doesn't come too late in the development cycle.

Regards,
Jerome


Greg Wilkins a écrit :
> Jerome,
> 
> the servlet API is used for the base request/response for Jetty6.
> 
> But note this does not prevent you using an alternative framework,
> because it is just and API and the servlet facilities are not 
> enabled in that API until the request has passed the appropriate
> ContextHandler, SessionHandler, SecurityHandler, ServletHandler.
> 
> Without these handlers, APIs like getSession will return null
> (unless you have a handler that calls setSession).
> 
> Not also that the jetty Request/Response classes are more than
> just the servlet API, as they have setters as well as getters.
> 
> So semanticly, Jetty6 handlers are no different to Jetty5 handlers
> is their nature or power.  They just need an extra small jar to
> run (but still smaller than the glue code in jetty 5).
> 
> It is pretty much a final design decision- I know it initially
> feels horrible, but it grew on me once I realized that there is
> really no reason to have two signatures for getRequestURI !
> 
> but if you really don't like it - please try to convince me!
> 
> Also - Jetty 6 has lots of NIO support and can do a lot more
> work in non-blocking mode.
> 
> The latest release is already a little old and I will try to
> do a new release shortly once the move to codehause SVN settles down.
> 
> cheers
> 
> 
> Jerome wrote:
>> Hi all,
>>
>> In Jetty 5, I was able to create a custom HTTP server by sub-classing
>> the SocketListener and HttpConnection classes. Beside a dependency on
>> the Cookie class, this allow me to have almost no dependency on the
>> Servlet API.
>>
>> That was important to me as I have developed an alternative framework to
>> the Servlet API (with full non-blocking IO support and RESTful design),
>> and now I wonder if I will be able to port that work to Jetty6.
>>
>> Indeed, it seems that there is no more abstraction layer between the
>> HTTP protocol classes and the Servlet API implementation. I am missing
>> something and if not is this a final design decision?
>>
>> Thanks,
>> Jerome Louvel