Hi,
Paul Sandoz wrote:
> 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
As far as Comet is concerned, +1 :-)
>
> 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.
+1
-- Jeanfrancois
>
> Paul.
>