On Oct 27, 2012, at 6:09 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> Marek,
>
> please find my answeres inlined in green.
>
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Samstag, 27. Oktober 2012 16:36
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: New abstract methods in Response
>
>
> 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?
>
> Gosh, you are absolutely right! It in fact seems I was kind of totally blind when coding it back some months (I assume I was back then driven by the JAX-RS 1.1 java docs which said that an application may extend…)! In fact WebDavResponse.multistatus() already isimplemented as…
>
> public static ResponseBuilder multistatus() {
> return Response.status(MULTI_STATUS);
> }
>
> ...and the extending of Response in totally useless!
>
> Weird. Possibly the reason why I did not commit that to SVN so far. ;-)
>
> So I now simply removed all the unnecessarily implemented methods that I just wrote to fulfil the abstract class when not extending Response, which in fact makes my class much shorter. Seems I was kind of drunk or tired when I wrote the original source. Thanks for telling me, really. I just modified the source so I hereby revoke my initial objection against your proposal! Go on with what you planned! :-)
>
>
> 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.
>
> I did not recognize this fact but now am totally thankful for your defense. :-)
>
>
> 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.
>
> No, my intention was absolutely and explicitly not to "piss you off", not at all. I really simply wanted to know whether the policy changed about BW incompatibility as I remembered the disccusion from months back and thought your decision back then was to not break it. So I simply remembered wrong or misunderstood the old discussion results. See, as I am volunteering on JAX-RS, I have to do the discussions late at night, so I might have missed some points (like others did, too) as I am simply too tired to give my full concentration on all what has ever been said on the ticker. Sorry.
>
> About my comments. Some of them (in other mails) where ment sarcastic (as the direction some threads went after time looked to me rather ironic, looking at the API from a user's view) and I know from other Experts that they understood them correctly and shared my points (even if they did not say so on the forum -- not everything must be discussed public, e. g. who is pissed of when and why). I learned from Santiago that some did not see the humor in them, so I said I will abstain and did so far!
>
> In the special case here, it actually was neither meant funny nor aggresive! Really! No Joke! In fact I was shocked reading that you think I want to "piss you off" with my comment. If you would know me privately, you would know that I never want to "piss off" anybody but only fight in a hard style (even verbally) for the targets I want to reach. This possibly can be understood as personal aggression, targeting other people, but it actually only targets the API. My intention was only to get an answer. Not more. See, English is not my mother's tongue. Maybe the way I write things is understood in a different way than I intended it. I am sorry for that. I did not intend my comments to be aggravating but actually want to get answers to my questions or want to propose changes to the spec. Not more. Not less. I never ever had the intention to "piss off" anybody in this forum. If my mails had been understood in that way I am sorry about that. Maybe it is better if I do not participate in textual discussions but simply put my concerns into JIRA issues and let you decide how to fix them, this might be simple than lengthy discussions (like I do it with other products, like GlassFish).
>
> On the other hand, please do not try to be "pissed off" too easily and mind that it might have an agressive touch too, to be "pissed off" too easily, or when experts as questions several times and simply do not get a sufficient answer, like it happened several times in the last time. Neither me, Jan or others, where pissed of due to that but simply rephrased the question. So please, just expect my questions to be honest interest in the topic, not a means of personal aggression.
That's what I would indeed expect.
Also, I did not expect that my comment would be accepted without a retort. I said what I wanted to say and when I felt it's time to already say something. And for the sake of restoring the technical discussion I'm not going to continue in this conversation. (Now feel free to have the last word...)
Marek
>
> Regards
> Markus
>
>
> 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
>
>
>
>
>
>