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]
