On Oct 25, 2012, at 11:21 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> WebDavResponse.multistatus(…) works similar to Response.ok(…): It provides a convenient way to produce the typical WebDAV response of "207 Multi-Status" (http://www.webdav.org/specs/rfc2518.html#status.code.extensions.to.http11) without having to write Response.status(MULTI_STATUS), hence is as essential to WebDAV as ok() is for vanilla http.
Given we're talking about a static method on WebDavResponse, which I assume returns a ResponseBuilder (which is not said to be extensible even in JAX-RS 1.x), why do you need to extend Response in this case?
>
> The WebDavResponse class is existing already, but is not found in the public downloads so far as it was prepared for the next release of WebDAV Support for JAX-RS, which I intended to ship when migrated to JAX-RS 2.0. So you would invalidate an already made investment in source code, what I am not happy about.
>
> Can you please provide a code example how implementing und using .multistatus() would look like using your proposed delegation solution so I can see whether it would work and what it actually means to me and my users?
I believe you already provided the implementation above:
Response.status(MULTI_STATUS)
Still I don't see where the Response extension is needed in this case.
> BTW, I wonder why breaking backwards compatibility suddenly is no issue anymore as I can remember some months back I was near to get lapidated for proposing breaking backwards compatibility…?! I mean, if there are any users out there which have existing Response implementations (Who knows? Who has collected valid statistics?) their application simply will not run anymore. Ain't that an issue? (Just for curiosity, as apparently you seem to plan to provide a tailored solution for my case)
If it wasn't an issue, I would not be writing a special email asking you for a feedback! If there are only very few applications that wrap Response and would need to update and recompile when deploying to the new JAX-RS runtime, I'd still be ok with that. But I would certainly want to prevent breaking many apps if we find out that there's a major use case I failed to see.
As for the issue you proposed (regarding UriBuilder), we're implementing it despite the fact that it is clearly BV incompatible also when it comes to TCK and I've spend days defending the decision on this mailing list as well as I am still spending a lot of time dealing with all the processes around changing the TCK to make the change you requested possible.
So, if your goal was to just piss me off with your last comment, you made it. FWIW, I do not understand why you need to include aggravating comments in your emails. It's not funny and does not help to move the discussion further or improve anything at all.
Marek
>
> Thanks
> Markus
>
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Donnerstag, 25. Oktober 2012 22:57
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: New abstract methods in Response
>
>
> 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
>
>
>
>
>