users@jersey.java.net

Refactoring the container SPI

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 06 Jun 2008 15:14:04 +0200

Hi,

There are two use-cases that require refactoring of the container SPI:

1) Support for comet where a response is kept alive and used to
    write/push further responses; and

2) Filtering.

in addition i think i can improve the ease of use of integrating containers.

Currently it is necessary to extend the
AbstractContainerRequest/Response classes with container specific
classes. Instead the ContainerRequest/Response interfaces will be turned
into non-abstract classes with the same functionality as
AbstractContainerRequest/Response.

   public class ContainerRequest implements HttpRequestContext {
     ContainerRequest(
         WebApplication wa,
         String method,
         URI baseUri,
         URI requestUri,
         MultivaluedMap<String, String> headers,
         InputStream entity
         );

         ...
   }

   public class ContainerResponse implements HttpResponseContext {
     ContainerResponse(
         WebApplication wa,
         ContainerRequest request,
         ResponseWriter adapter
         );

         // write the response
         write() throws IOException;

         // reset the state of the response so it can be used for
         // writing further responses
         reset();

         ...
   }

   public interface ResponseWriter {
     // Write the status and headers and
     // return an output stream to write the
     // entity
     // The OutputStream.close method must not be called
     OutputStream writeStatusAndHeaders(
         long contentLength,
         ContainerResponse response
         ) throws IOException;
   }

It is the responsibility of the container to provide an an instance of
ContainerRequest and an implementation and instance of ResponseWriter.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109