Hi,

IMHO the problem is in this line:

StringEntity entity = new StringEntity(new String(output.toByteArray()),
ContentType.TEXT_XML);

Charset is not specified when constructing a String instance, so a system
default one is used, most likely UTF-8 on linux.
And then StringEntity wants to have bytes out of it, but as ISO-8859-1.
The solution should be using e.g. ByteArrayEntity here (as content is
already available as bytes) and not messing with strings/charsets.

Regards,
Alex


On Thu, Feb 26, 2015 at 6:35 PM, Oleg Kalnichevski <[email protected]> wrote:

> 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]
>
>

Reply via email to