users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: HEADS-UP: Encoding values of UriBuilder template parameters

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 22 Dec 2011 18:25:11 +0100

Actually, the plan is not to "change" existing javadoc, we are going to extend it to address the gray areas not
currently covered at all. In addition, we will add a new fallback build(...) method that would preserve the
functionality enforced by the TCK tests (without any obvious support from the spec). At last, we will need to fix the
respective TCK tests that currently enforce behavior reported as bug/inconsistent with @Path annotation.

Marek

On 12/21/2011 06:24 PM, Markus KARG wrote:
> A JavaDoc change is all I asked for (while I would really love to see the API work as I proposed, instead). :-) But note
> that segment() is currently NOT able to encode slashes in JAX-RS 1.0, as I wrote you privately before, so to get %2F one
> must actually encode this MANUALLY at the moment (I want to get rid of String.ReplaceAll)! So technically spoken, you
> won't break too much anyways… ;-)
>
>
>
> BTW, there is one issue that is really bad: There are lots of overloaded path() signatures being able to use an
> annotation's path. But those do not exist for segment(). So how to get this working with automatic %2F encoding? If you
> don't change the actual implementation, then one must MANUALLY check the value of @Path and apply ReplaceAll("/","%2F")
> every time. It would make much sense to copy the overloaded signatures into new versions fo segment() then, e. g.
> segment(Class) and segment(Class, String) so one would get the automatic encoding of slashes without dealing with
> Reflection API.
>
>
>
> Regards
>
> Markus
>
>
>
> *From:*Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
> *Sent:* Donnerstag, 8. Dezember 2011 19:46
> *To:* jsr339-experts_at_jax-rs-spec.java.net
> *Cc:* Markus KARG
> *Subject:* Re: [jax-rs-spec users] [jsr339-experts] Re: HEADS-UP: Encoding values of UriBuilder template parameters
>
>
>
>
>
> On Dec 8, 2011, at 5:07 AM, Marek Potociar wrote:
>
>
>
> Check the JAX-RS 1.x UriBuilder javadoc for path(String) and segment(String...):
>
> http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriBuilder.html#path%28java.lang.String%29
> <http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriBuilder.html#path(java.lang.String)>
> http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriBuilder.html#segment%28java.lang.String...%29
> <http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriBuilder.html#segment(java.lang.String...)>
>
> It contains explicit and unambiguous explanation of the difference between encoding segment and path template values as
> you requested earlier in your email. What we should do in this space wrt issue JAX_RS_SPEC-70 is to improve the summary
> information about encoding the template values in the class-level javadoc (once we reach an agreement), which is
> currently incomplete and does not explicitly take path segments or matrix parameters into account even though they are
> clearly supported by the API as independent contextually encoded entities.
>
> I hope that from the referenced javadoc it is clear that in order to support your proposal in JAX_RS_SPEC-70 we would
> need to break the UriBuilder javadoc, which means breaking BW compatibility of the API at the application level, which
> we simply cannot do.
>
> As I tried to outline earlier, what you want to achieve can be provided via UriBuilder.segment(...) method. This would
> preserve BW-compatibility with the 1.x API.
>
>
>
> It's good that you brought this up. I was under the impression the proposal in JAX_RS-SPEC-70 was not BW compatible,
> and the Javadoc makes that clear.
>
>
>
> -- Santiago
>
>
>