I think I've hit a similar issue, but with a different use case. Stacktrace
from Jetty included, but same problem in JBoss as well. I think this is a
similar problem. The result is truncated when I include multibyte characters
in the output. Problem does not exist if I only have 8-bit ISO 8859
characters in the output.
I suspect it has to do with the length of the outputs. Something in the
CharsetEncoder or OutputStreamWriter that cause the outputstream to be
closed after n bytes have been output instead of n characters. For 8-bit
chars, the number of bytes are the same, but for UTF-8 encoding, that's not
the case.
I'd like to find out if this is a known issue. Otherwise, I can create a
ticket as well. Going to dig through some of the JDK source code too as I
suspect the problem is in there.
===
[java] May 20, 2007 10:43:53 PM
com.noelios.restlet.http.HttpServerConverte
r commit
[java] INFO: Exception intercepted
[java] java.io.IOException: Closed
[java] at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGene
rator.java:612)
[java] at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGene
rator.java:570)
[java] at
sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
[java] at
sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
[java] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
[java] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
[java] at
java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
[java] at java.io.Writer.write(Writer.java:140)
[java] at
org.restlet.resource.StringRepresentation.write(StringReprese
ntation.java:203)
[java] at
com.noelios.restlet.http.HttpServerCall.writeResponseBody(Htt
pServerCall.java:331)
[java] at
com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServ
erCall.java:305)
[java] at
com.noelios.restlet.ext.jetty.JettyCall.sendResponse(JettyCal
l.java:219)
[java] at
com.noelios.restlet.http.HttpServerConverter.commit(HttpServe
rConverter.java:90)
[java] at
com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHe
lper.java:95)
[java] at
com.noelios.restlet.ext.jetty.JettyServerHelper$WrappedServer
.handle(JettyServerHelper.java:232)
[java] at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection
.java:469)
[java] at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplet
e(HttpConnection.java:791)
[java] at
org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
[java] at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:2
09)
[java] at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:3
58)
[java] at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEnd
Point.java:365)
"Irfan Jamadar" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi
>
> I am a colleague of Sreenivas Reddy, and thus have been owkring on the
> same application which utilises the restlet framework.
> We have recently started to utilise the application in an international
> sense i.e. introduce languages such as Turkish, Polish etc.
> This has led to issues with character set encoding, even though we have
> correctly utilised UTT-8 throught.
> These problems however appear to have been fixed with the recent fixes
> (in the realm of InputRepresentation, getText, toString etc).
> But one problem is still persisting, when we PUT an XML entity to the
> framework. Even though the Content-Type are correctly set
> i.e. application/xml;charset=UTF-8
> Basically the Entity that comes through on the restlet Request object has
> not been correctly encoded (shown by the fact that it has been truncated
> by N bytes).
> For example:
>
> <test>
> <description>Á<description>
> </test>
>
> Becomes:
>
> <test>
> <description>Á<description>
> </test
>
> Since the 'Á' character occupies two bytes.
>
> I have eliminated our actual application from the equation by writing a
> very simple stand alone test to replicate the error.
> Is there somewhere I can provide this example app, to help in resolving
> the problem?
>
> Cheers;
> Irfan
>
