[
https://issues.apache.org/jira/browse/CXF-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229823#comment-14229823
]
Sergey Beryozkin commented on CXF-6122:
---------------------------------------
Hmm...
I've just updated JAXRS20ClientServerBoomTest testGetBookSyncLink.
{code:java}
String address = "http://localhost:"; + PORT + "/bookstore/bookheaders/simple";
WebClient wc = createWebClient(address);
wc.query("phone", "+44 123");
Book book = wc.sync().get(Book.class);
{code}
and a client filter to print getUri() value and I see the filter printing a
properly encoded value such as:
"http://localhost:9001/bookstore/bookheaders/simple?phone=%2B44+123";.
Using UrlEncoder explicitly leads to the double encoding - but the filter does
not print a decoded URI value.
I then updated a proxy based test and got the properly encoded URI displayed
too.
I wonder, do you have some 3rd party JAX-RS implementation loaded which may
lead to CXF proxy picking up a 3rd party UriBuilder implementation loaded ?
Can you provide a test case or debug ?
Sergey
> JAX-RS proxy client with @QueryParam is not encoding the parameter value
> ------------------------------------------------------------------------
>
> Key: CXF-6122
> URL: https://issues.apache.org/jira/browse/CXF-6122
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.0.2
> Reporter: Konrad Windszus
>
> If I create a JAX-RS client with the proxy pattern outlined at
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
> and the proxy interface looks like this
> {code}
> @PUT
> @Path("/admin/user/{id}.json")
> @Produces(value = { "application/json" })
> public User updateUser(@PathParam("id") String userId,
> @QueryParam("country") String country, @QueryParam("description") String
> role, @QueryParam("telephone") String phone);
> {code}
> all URL parameters are not correctly encoded.
> E.g. if phone contains a "+" this will not be converted to %2B or if the role
> contains an umlaut this will not be encoded either.
> Another related question is: Which character set will be used here (I guess
> UTF-8 makes sense) once that bug is fixed? Also how would it be possible to
> override the character set?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
