On Oct 25, 2012, at 7:53 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> I am sorry that I have to object that application classes my not extend Response anymore, as the WebDAV Support for JAX-RS needs this as an extension point to provide the possibility to simply write:
>
> WebDavResponse.multistatus(…);
What would that do? How would it translate to Response method calls?
>
> So I have to object. It must still be possible for non-JAX-RS-implementors to extend Response. Or the JAX-RS 2.0 must provide another extension point for things like WebDAV.
Are you saying you are already extending Response or that someone may want to extend Response? Would it work for you, if we provided an AbstractResponseDelegate, that would implement delegation to a wrapped Response instance and would be available for customization and extension? That way you would be able to extend the response behavior with new convenience methods that would call the wrapped Response methods. Would that work?
Marek
>
> Regards
> Markus
>
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Donnerstag, 25. Oktober 2012 14:59
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] New abstract methods in Response
>
> Hello experts,
>
> As you know we've added quite a lot of new abstract methods to the Response API. The approach is however somewhat problematic, because Response javadoc states that:
>
> An application class can extend this class directly or can use one of the static methods to create an instance using a ResponseBuilder.
>
> So, adding new abstract methods is strictly speaking a BV incompatible change. Still, we are not aware of any application developer extending the Response class. Are you?
>
> We thought we would change the javadoc to not support extending Response anymore and at the same time implement the newly added methods. Yet, as it turns out, the only practical default implementation would be to throw an UnsupportedOpperationException in most cases. Otherwise we would have to bring in a lot of internal utility classes from Jersey into the API and the implementation would still only work on the server side. Therefore we feel that it would be best to keep the new methods abstract and only change the javadoc to state that:
>
> An application class should not extend this class directly. Response class is reserved for an extension by a JAX-RS implementation providers. An application should use one of the static methods to create a Response instance using a ResponseBuilder.
>
> Again, this is a BW-incompatible change. But we don't know any application that would be really extending the Response class.
>
> Let us know what you think about the proposal. Given the full context, would you support it even if it is BW-incompatible change?
>
> Thanks,
> Marek
>
>
>
>