Thanks for the reply guys, once I finish the route/unit tests I will try
with the latest versions.
I ended up creating a utility method to reset the StreamCache when
obtaining the body in our custom EventNotifier and InterceptStrategy.
The route is quite simple:
<route>
<from uri="servlet:///myService" />
<to uri="bean:myTransformerBean?method=transformRequest" />
...
</route>
The EventNotifier is called for ExchangeCreatedEvent on
"servlet:///myService" and instead of using
exchange.getIn().getBody(String.class) I've created the utility methods:
(Groovy-ish)
static String getBodyAsString(Exchange exchange) {
String result
Object body = exchange.getIn().getBody()
if (body) {
if (body instanceof StreamCache) {
String charset = exchange.getProperty(Exchange.CHARSET_NAME, "UTF-8")
result = readStreamCache(body, charset)
} else {
result = exchange.getIn().getBody(String.class)
}
}
}
static String readStreamCache(StreamCache stream, String charsetName) {
ByteArrayOutputStream baos = new ByteArrayOutputStream()
stream.writeTo(baos)
stream.reset()
return baos.toString(charsetName)
}
Henrique Viecili
On 14 April 2014 22:50, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
>
> Can you try using Camel 2.12.x or better with the latest 2.13 as the
> stream caching support has been improved in these releases.
>
> If its still an issue we may want to take a look at letting Camel
> reset the stream cache (if needed) when you use custom event
> notifiers.
>
> On Sun, Apr 13, 2014 at 8:57 PM, Henrique Viecili <viec...@gmail.com>
> wrote:
> > I've just faced an interesting issue with a StreamCache body being
> > 'exausted' after calling exchange.getIn().getBody(String.class) inside an
> > EventNotifier
> >
> > I'm using Camel 2.10.0 (inside JBoss Fuse 6.0) and captured an
> > ExchangeCreatedEvent on a HTTP endpoint (input). The payload was an
> > instance of InputStreamCache and after the EventNotifier executed I got a
> > 'Premature End of File' trying to parse the body as xml in the pipeline.
> >
> > Looking at the source code of InputStreamCache (extends
> > ByteArrayInputStream) the writeTo method uses IOHelper.copy which
> > 'consumes' the underlying byte array, so a next call would throw some
> > IOException. I reckon this behaviour is correct according to the
> interface
> > StreamCache.
> >
> > What I wonder is whether the automatic TypeConversion should (or not) try
> > to reset() the StreamCache after doing the type conversion, avoiding such
> > situations.
> >
> > Does this make sense? Is this fixed in the latest versions or I should
> > raise a JIRA?
> >
> > Regards,
> > Henrique Viecili
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>
