cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-6122) JAX-RS proxy client with @QueryParam is not encoding the parameter value
Date Mon, 01 Dec 2014 14:15:13 GMT


Sergey Beryozkin commented on CXF-6122:


I've just updated JAXRS20ClientServerBoomTest testGetBookSyncLink. 
String address = "http://localhost:" + PORT + "/bookstore/bookheaders/simple";
WebClient wc = createWebClient(address);
wc.query("phone", "+44 123");
Book book = wc.sync().get(Book.class);

and a client filter to print getUri() value and I see the filter printing a properly encoded
value such as:

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 ?


> JAX-RS proxy client with @QueryParam is not encoding the parameter value
> ------------------------------------------------------------------------
>                 Key: CXF-6122
>                 URL:
>             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
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

View raw message