Hi Roman,
yes, you are right, this was a bug in the StringProvider. It's fixed in
the trunk now. Does it work for you now?
Sorry for the delay, because I have to do a lot of other things in the
moment I do not read the mailing list emails fast. If you note in the
subject that it's a problem for JAX-RS, than I will read it earlier perhaps.
best regards
Stephan
Roman Geus schrieb:
Hi Thierry
To my knowledge my example uses only Restlet classes, i.e.
javax.ws.rs.core.Response
I think the problem could be in
org.restlet.ext.jaxrs.internal.provider.StringProvider.getSize(...).
It returns the number of characters, but the docs of
javax.ws.rs.ext.MessageBodyWriter.getSize(...) say it should return
the number of bytes in serialized form.
Hope it helps,
Roman
Thierry Boileau wrote:
Hi Roman,
when I have a look at the source code of the StringRepresentation
class, I notice that the length is computed on via the "getBytes"
method which should calcute the correct length.
I have a few questions: as I think that this code
("Response.ok().entity(result).build();") is certainly base on some
of your own classes, we would like to know what kind of
Representation are you using? Is it possible for you to update the
character set of the returned representation and test with several
charsets?
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Hi all
I have run across a problem, where the last few bytes of the entity
body are not transferred to the client.
The problem occurs if the number of characters in the entity body
does not match the number of bytes in the encoded string (in my case
UTF-8).
Example 1:
@GET
@Produces("text/plain")
public Response dsearch() {
String result = "Romän";
return Response.ok().entity(result).build();
}
Here Restlet sets the the Content-Length to 5, the client receives
the bytes 122 157 155 303 244 (in octal) corresponding to the string
"Romä". The last character "n" got lost.
Restlet seems to set the Content-Length to the number of characters
in the entity instead of to the number of bytes of the encoded
string, causing the loss of trailing characters.
Example 2:
@GET
@Produces("text/plain")
public Response dsearch() {
String result = "Romän";
return Response.ok().entity(result.getBytes()).build(); //
note the getBytes() call
}
This case works fine: Restlet sets the the Content-Length to 6, the
client receives the bytes 122 157 155 303 244 156 (in octal)
corresponding to the full string "Romän".
Is it a bug or a feature?
Cheers,
Roman
