WORA could easily be achieved with a properties file. I think Marek and
I are on the same page on this. I agree with him, I don't think JAX-RS
is ready (or is even the right place) to standardize a caching API. As
a JAX-RS implementor and a cache provider, I personally do not want to
be constrained by a specification in this regards. Especially when Red
Hat is already leading or participating in other caching JSRs.
I think we need to focus on the API/SPIs that give us the abstractions
we need to write value-adds like caching. Specifically a client
framework and client/server side interceptors.
On 5/13/11 2:17 PM, Markus KARG wrote:
> How shall an application do WORA then? You are enforcing proprietary apps. That is counterproductive to the idea of a Java EE standard.
>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Freitag, 13. Mai 2011 13:35
>> To: Marek Potociar
>> Cc: jsr339-experts_at_jax-rs-spec.java.net; Markus KARG
>> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
>> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>>
>>
>>
>> On 5/13/11 6:34 AM, Marek Potociar wrote:
>>>
>>>
>>> On 05/12/2011 07:43 PM, Markus KARG wrote:
>>>> Agreed, but in a standalone client application the application's
>> http transport provider is provided by the JAX RS Implementation, isn't
>> it? How should an application enable caching then?
>>>
>>> Through a proprietary client provider API.
>>>
>>
>> Or through proprietary properties.
>>
>> i.e.
>>
>> import javax.ws.rs.client.Client;
>>
>> Client c = new Client();
>> c.setProperty("resteasy.client.cache", true);
>>
>>
>> Bill
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com