Hi Paul,
Thanks for the pointers. I am starting to understand how caching works.
Here is my understanding of how we should generate code to support
caching in the resource classes we generate from entity classes.
First, we need to generate a memory store similar to the one in
the Storage sample. This memory store will keep track of the
digest and lastModified date of an resource.
Second, we need to change the return type for all the http methods
to Response. We will then use the precondition evaluator to
determine what response to send back. We will also us the CacheControl
to specify the caching policy for the resource.
Here are some questions:
1. Regarding etag (digest) and lastModified data, do we need both? We
will lose
all the lastModified dates after each restart but we can always recompute
the etags from the resource itself. So etag seems to be a more reliable
method.
2. If I call Response.Builder.representation(jaxbInstance) without the
mime type,
will it automatically serialize the jaxb instance into xml or json
depending on the
mime type in the request header? The reason I ask this is because we
currently
specify a list of mime types in the ConsumeMime and ProduceMime annotations.
Paul Sandoz wrote:
> Paul Sandoz wrote:
>>> Paul, you mentioned about etags and preconditions in jsr311,
>>> could you elaborate on this
>>
>> I will do better and defer to Mark Nottingham's caching tutorial [2].
>>
>> There are also a couple of other related things like using 100
>> (Continue) for POST'ing or PUT'ing large files (unfortunately this is
>> not possible using Servlet) and using ETags/Last-Modified with PUT to
>> avoid the lost update problem.
>>
>>
>>> and show how developers can program
>>> the caching behavior in the resource classes?
>>>
>>
>> I will send an email tomorrow how to support caching and preconditions.
>>
>
> A bit late....
>
>
> javax.ws.rs.core.CacheControl [1] can be created and set uding
> Response.Builder.cacheControl [2].
>
> Preconditions can be evaluated by using an injected
> PreconditionEvaluator [3].
>
>
> First you need to obtain the etag and/or last-modified date from
> somwhere. Call PreconditionEvaluator.evaluate with etag and/or date.
> If the call returns a non-null Response then preconditions have been
> met and you can return the response. Otherwise a response needs to be
> returned and you should set the etag and/or last-modified on a
> response and include any CacheControl instance as required.
>
> We can probably improve this behaviour by
> PreconditionEvaluator.evaluate returning an instance of
> Response.Builder so that this can be reused if preconditions are not met.
>
>
> Note that this will also work for 409 (Conflict) responses, so you can
> use when PUTing content as well as for GETing content.
>
> Paul.
>
> [1]
> https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/CacheControl.html
>
> [2]
> https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/Response.Builder.html#cacheControl(javax.ws.rs.core.CacheControl)
>
> [3]
> https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/PreconditionEvaluator.html
>
>
>> Paul.
>>
>> [1] http://roy.gbiv.com/talks/200709_fielding_rest.pdf
>> [2] http://www.mnot.net/cache_docs/
>>
>>> Thanks.
>>>
>>> Peter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>