Actually its not tomcats issue, when sending an encoding other than the default which is ISO-8859-1 according to RFC-2616 (HTTP/1.1) you should send the encoding type (i.e. text/xml;charset=utf-8). By default the JAXB marshaller will use UTF-8 encoding when marshalling.
You can switch Tomcat to use UTF-8 encoding everywhere by default by setting the URI encoding, adding an encoding filter such as [1](Springs CharacterEncodingFilter) implementation etc... follow details at [2](the tomcat wiki). What I'm guessing was happening was you were sending a character like a copyright symbol but instead of sending 0xA9 you were sending 0xC2 0xA9 [1]: http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/filter/CharacterEncodingFilter.html [2]: http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 On 2 Mar 2015, at 21:45, Alessandro Manzoni <[email protected] <mailto:[email protected]>> wrote: > Using InputStreamEntity and forcing UFF-8 as enconding in HttpPost the > problem was solved. InputStreamEntity only, without UFF-8, was not enough. > That's sond definitively as a Tomcat issue. > > Il 26.02.2015 13.35, Oleg Kalnichevski ha scritto: >> On Thu, 2015-02-26 at 13:28 +0100, Alessandro Manzoni wrote: >>> Thank you Oleg, >>> Il 26.02.2015 09.52, Oleg Kalnichevski ha scritto: >>>> On Thu, 2015-02-26 at 19:04 +1100, Brett Ryan wrote: >>>>>> Since I produce the xml in memory, that's the way Marshal.marshal method >>>>>> works, I could use the ByteArrayEntity using the byte[] from the >>>>>> ByteArrayOutputStream supplied to marshal. >>>>> Could you not do something like >>>>> >>>>> PipedOutputStream out = new PipedOutputStream(); >>>>> InputStream instr = new PipedInputStream(out); >>>>> marshaller.marshal(object, out); >>>>> HttpPost post = new HttpPost(); >>>>> post.setEntity(new InputStreamEntity(instr)); >>>>> >>>> A custom HttpEntity implementation that internally makes use of JAXB >>>> marshaling would be massively more efficient. >>>> >>>> Oleg >>> I agree with you, but efficiency is not an issue. >>> The client is manageg by an application that gather data to send as an >>> xml to the target Tomcat. >>> Data are validated by marshalling before sending by HTTPCLient. >>> If validation didn't pass, a notification of invalid data is sent to >>> another service. When validation is succesfull, validated data is sent >>> by http client. >>> So putting validation into a custom entity would be a duplicated >>> operation, then the responsability of validation is not a transport >>> agent one. Don't you agree? >>> >> HttpEntity is essentially a data producer meant to encapsulate whatever >> data generation mechanism there already is, including validation and >> what not. No code duplication should ever be necessary. >> >> Oleg >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> >
