what's the encoding used by the tomcat jvm? If it's let's say ISO 8859-1 that would explain everything.
Sendt fra min iPhone > Den 2. mar. 2015 kl. 11.45 skrev Alessandro Manzoni > <[email protected]>: > > 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] >> For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
