Awesome Paul, I thought something wasn't quite right. I've done as you
suggested, overriding setContextType and after call to super, sets this
manually from what I can extract from PageInfo.
Btw. while browsing around the source, I noticed an improved filter I
would deem especially suitable to Jersey and REST in general:
http://ehcache.svn.sourceforge.net/viewvc/ehcache/trunk/web/src/main/java/net/sf/ehcache/constructs/web/filter/SimpleCachingHeadersPageCachingFilter.java?view=markup
It adds support for the HTTP caching headers, thus my previous response
log now become:
Server Apache-Coyote/1.1
Last-Modified Mon, 09 Nov 2009 12:16:27 GMT
Expires Mon, 09 Nov 2009 12:16:57 GMT
Cache-Control max-age=30
Etag Mon, 09 Nov 2009 12:16:57 GMT
Content-Encoding gzip
Content-Length 1129
Date Mon, 09 Nov 2009 12:16:27 GMT
Notice btw. the continued absence of a Content-Type header. I'll try to
contact the EhCache people through another channel.
Thanks again,
Casper
Paul Sandoz wrote:
> Hi Casper,
>
> Looking at the source of SimplePageCachingFilter that extends from
> CachingFilter [1] i think it might be a bug in the
> GenericResponseWrapper class [2].
>
> An instance GenericResponseWrapper maintains its own state for the
> content type and headers and ignores those on the underlying wrapped
> response.
>
> You can verify this by extending from SimplePageCachingFilter and
> overriding the methods on CachingFilter for setting the headers and
> content type.
>
> Paul.
>
> [1]
> http://www.java2s.com/Open-Source/Java-Document/Cache/ehcache/net/sf/ehcache/constructs/web/filter/CachingFilter.java.htm
>
> [2]
> http://www.java2s.com/Open-Source/Java-Document/Cache/ehcache/net/sf/ehcache/constructs/web/GenericResponseWrapper.java.htm
>
>
> On Nov 9, 2009, at 11:28 AM, Casper Bang wrote:
>
>> I'm exploring caching options with Jersey, particularly ways to utilize
>> EhCache. For a simple high-performance read-only Jersey instance, the
>> SimplePageCachingFilter that comes with EhCache is an interesting option
>> as it caches a gzipped HTTP response right at the forefront. However I
>> noticed that when the filter is activated, it does not forward the
>> original Content-Type from lower down the filter chain (Jersey). An
>> example without caching:
>>
>> Server Apache-Coyote/1.1
>> Content-Type application/xhtml+xml
>> Transfer-Encoding chunked
>> Date Sun, 08 Nov 2009 10:13:02 GMT
>>
>> And now, with caching:
>>
>> Server Apache-Coyote/1.1
>> Content-Encoding gzip
>> Content-Length 1130
>> Date Sun, 08 Nov 2009 10:15:58 GMT
>>
>> I wonder what goes wrong, whether I am not using it correctly. In my
>> web.xml, the caching filter is listed before the Jersey filter and apart
>> from this header rewrite, everything works flawlessly. I assume it's not
>> simply because the caching filter automatically compresses the cached
>> response, even if compressed, the Content-Type would still be relevant
>> to the client? According to rfc2616 my expectation is entirely valid:
>>
>> 14.11 Content-Encoding
>>
>> The Content-Encoding entity-header field is used as a modifier to the
>> media-type. When present, its value indicates what additional content
>> codings have been applied to the entity-body, and thus what decoding
>> mechanisms must be applied in order to obtain the media-type
>> referenced by the Content-Type header field. Content-Encoding is
>> primarily used to allow a document to be compressed without losing
>> the identity of its underlying media type.
>>
>>
>>
>>
>> Can anyone shed some light on what goes on here? I realize this is more
>> suitable to be addressed to EhCache developers but I've had no response
>> from there and I assume the general topic of caching is relevant to many
>> developers using Jersey. Could this be an oversight/bug in the filter?
>>
>> Thanks,
>> Casper
>>
>> ---------------------------------------------------------------------
>> 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
>