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>
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 is implemented 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.
Regards
Markus
Marek
Thanks
Markus
From: Marek Potociar [mailto:marek.potociar@ <
http://oracle.com> oracle.com]
Sent: Donnerstag, 25. Oktober 2012 22:57
To: <mailto:jsr339-experts_at_jax-rs-spec.java.net>
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 < <mailto:markus_at_headcrashing.eu>
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@ <
http://oracle.com> oracle.com]
Sent: Donnerstag, 25. Oktober 2012 14:59
To: <mailto:jsr339-experts_at_jax-rs-spec.java.net>
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