Very good, thanks!
On Thu, 12 Jun 2008 16:49:53 +0200, Paul Sandoz <Paul.Sandoz_at_Sun.COM>
wrote:
> Keith R. Davis wrote:
>> Stupid question: will this require my existing application to re-factor
>> existing servlet filters that I am using with 0.7ea?
>>
>
> No, it will not affect servlet filters (which will be at a layer lower
> than the Jersey runtime, so it does not know about them).
>
> Paul.
>
>> On Thu, 12 Jun 2008 16:30:43 +0200, Paul Sandoz <Paul.Sandoz_at_Sun.COM>
>> wrote:
>>> Hi,
>>>
>>> Now that the container SPI is refactored we can move on to specifying
>>> filters.
>>>
>>> Any filter SPI cannot be stack based (like the Russian doll filter API
>>> on Jersey client-side) because Jersey server-side needs to be in
> control
>>> of the stack (e.g. writing out multiple responses for comet).
>>>
>>> The disadvantage of a non-stack-based approach is it means state cannot
>>> be as easily shared between inbound and outbound filtering. But how
>>> common is that on the server side?
>>>
>>> So i propose the following provider interfaces:
>>>
>>> public interface ContainerRequestFilter {
>>> ContainerRequest filter(ContainerRequest request);
>>> }
>>>
>>> public interface ContainerResponseFilter {
>>> ContainerResponse filter(ContainerResponse response);
>>> }
>>>
>>> An implementation can throw a WebApplicationException to terminate the
>>> filter chain prematurely with it's own response.
>>>
>>> A provider implementation could consist of:
>>>
>>> @Provider
>>> public class MyFilter
>>> implements ContainerRequestFilter, ContainerRequestFilter {
>>> ...
>>> }
>>>
>>> and thus only one instance would be created for both in-bound and
>>> out-bound filtering, which means thread-local state could be shared.
>>>
>>> The next question is how to order/prioritize filters.
>>>
>>> I think the application should declare two lists of filter classes, for
>>> inbound and outbound. This makes it easy to specify using
> ResourceConfig
>>> or in the web.xml.
>>>
>>> Here is an example of what a transport-based GZIP filter might look
> like:
>>>
>>> @Provider
>>> public class GZIPFilter
>>> implements ContainerRequestFilter, ContainerRequestFilter {
>>>
>>> ContainerRequest filter(ContainerRequest request) {
>>> if (transport encoding is GZIP) {
>>> request.setEntity(new GZIPInputStream(request.getEntity());
>>> }
>>> return request;
>>> }
>>>
>>> private static class GZIPWriter
>>> implements ContainerResponseWriter {
>>> ContainerResponseWriter crw;
>>>
>>> GZIPWriter(ContainerResponseWriter crw) { this.crw = crw; }
>>>
>>> OutputStream writeStatusAndHeaders(
>>> long contentLength,
>>> ContainerResponse response) throws IOException {
>>> OutputStream o = crw.writeStatusAndHeaders(contentLength,
>>> response);
>>> return new GZIPOutputStream(o);
>>> }
>>> }
>>>
>>> ContainerResponse filter(ContainerResponse response) {
>>> if (transport encoding is GZIP) {
>>> response.setContainerResponseWriter(
>>> new GZIPWriter(response.getContainerResponseWriter()));
>>> }
>>> return response;
>>> }
>>> }
>>>
>>> We need the above as well as logging, fake PUT/DELETE, URI-based
> conneg,
>>> URI C14N with redirection filters.
>>>
>>> This is a long shot but it may even be possible to reuse such filters
>>> specifically targeted at resources.
>>>
>>> Paul.
>>>
>>> --
>>> | ? + ? = To question
>>> ----------------\
>>> Paul Sandoz
>>> x38109
>>> +33-4-76188109
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net