Sorry, I'm getting confused a bit.
If your service method returns String then this String will be written
out to the output stream and this String is expected to be a correct
representation. The default String provider is correct, the class/etc
parameters are not checked in the code because the provider is
statically typed to support String and the runtime guarantees that only
String classes will be provided to it.
Can you provide more info please.
By the way, that escape property I mentioned, it is actually set to
false by default, sorry. I have this test:
@Test
public void testDoNotEscapeForwardSlashes() throws Exception {
JSONProvider<Book> provider = new JSONProvider<Book>();
ByteArrayOutputStream bos = new ByteArrayOutputStream();
provider.writeTo(new Book("http://cxf";, 123), Book.class,
Book.class,
new Annotation[0],
MediaType.APPLICATION_JSON_TYPE,
new MetadataMap<String, Object>(), bos);
assertTrue(bos.toString().contains("\"name\":\"http://cxf\"";));
}
and another test where that property is enabled and the forward slashes
being escaped.
Sergey
On 30/12/15 02:58, Vincenzo D'Amore wrote:
And it at last comes out, what was wrong. It was the server response.
Basically a simple json string should not be returned instead of a json
object.
In other words:
"\/opt\/local\/application\/rest\/" is not a correct JSON object, it is
only a JSON string and should not be returned as response.
{ "path" : "\/opt\/local\/application\/rest\/" } is a valid JSON object and
can be considered a correct answer.
And again, the MessageBodyReader<String> must not decode the string (as it
does), because it should be the case where the user choose to read without
any modification and then understand what to do.
Please let me know your opinion.
On Wed, Dec 30, 2015 at 2:01 AM, Vincenzo D'Amore <v.dam...@gmail.com>
wrote:
Update.
Looking at CXF internals I discovered that StringTextProvider is used to
return the string object.
StringTextProvider implements MessageBodyReader<String> and
MessageBodyWriter<String>;
This is the readFrom implementation (called for MessageBodyReader):
public String readFrom(Class<String> type, Type genType, Annotation[]
anns, MediaType mt,
MultivaluedMap<String, String> headers, InputStream
is) throws IOException {
return IOUtils.toString(is, HttpUtils.getEncoding(mt, "UTF-8"));
}
As you can see all the parameter are useless, input stream is returned as
is.
How can I specify a different provider for strings?
On Wed, Dec 30, 2015 at 12:45 AM, Vincenzo D'Amore <v.dam...@gmail.com>
wrote:
Thanks Sergey,
but in the meanwhile I tried fruitless different options which include
escapeForwardSlashesAlways(false).
I have also tried to change entirely the implementation, but even Jersey
have the same behaviour.
This is pretty strange to me.
On Tue, Dec 29, 2015 at 7:10 PM, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:
Hi
This is to do with a default CXF JSONProvider which is Jettison based.
Jettison, historically, escapes forward slashes, I don't know why, it
was there when I started maintaining it.
What you can do is to configure CXF JSONProvider not to do it, set its
'escapeForwardSlashesAlways' to false.
Or use a Jackson provider instead (if you do - Make sure Jettison is on
on the classpath)
HTH, Sergey
On 29/12/15 14:40, Vincenzo D'Amore wrote:
Hi All,
I don't understand why when I receive a json encoded string this is not
decoded automatically.
I wrote this code:
Client client =
ClientBuilder.newClient().register(JSONProvider.class);
WebTarget target = client.target("http://example.org/rest/service1
");
target = target.queryParam("method", "method1");
Entity<EndpointRequest> entity = Entity.entity(new
EndpointRequest("0000"),
MediaType.APPLICATION_JSON);
Response response = builder.post(entity);
System.out.println( response.getStatus() );
if (response.getStatus() == 200) {
// The problem comes here
String basePath = response.readEntity(String.class);
System.out.println( basePath );
}
The request is successfully executed but basePath contains
"\/opt\/local\/application\/rest\/" (backslash and double quotes
included)
basePath should instead contain this: /opt/local/application/rest/
It seems to me, the json deserialization hasn't be triggered when it
should.
Thanks in advance for your help,
Vincenzo
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Vincenzo D'Amore
email: v.dam...@gmail.com
skype: free.dev
mobile: +39 349 8513251
--
Vincenzo D'Amore
email: v.dam...@gmail.com
skype: free.dev
mobile: +39 349 8513251
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
