If I need a properties file I do not reach WORA but I just reach that the change is moved from replacing a class file in a WAR to replacing a properties file a WAR. I do not expect that the WORA principle is dependent on the file type.
Also, I do not want to constraint you in any way. You are free to implement JAX RS as you like, as long as it comes with a local cache and as long as enabling it does not mean to change the WAR or server configuration (first is a no-go for ISVs, second is a no-go for Hosters).
Why not just agreeing on the most simple solution: All JAX RS implementations have to come with a (most simple but correct) cache implementation which can be enabled by a *standard* property name or a *standard* class name?
Example:
Client.setProperty(Client.CACHING_ENABLED)
or
Client.setFilter(Client.CACHING_FILTER)
???
This gives you any freedom you like, and prevents the user from any proprietary change. It just enforces one fact: You must bring a correctly working (even totally slim-fit in-memory JVM-private) cache with you. If your implementation has one already, great! If it works much better than Marek's, even better. Make it public and people will switch from Jersey to your implementation then.
Regards
Markus
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Freitag, 13. Mai 2011 23:58
> To: Markus KARG
> Cc: 'Marek Potociar'; jsr339-experts_at_jax-rs-spec.java.net
> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> 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