Hello! 

We are using ServiceMix 3.3 with Camel 1.4. As we dont want to build a new
servicemix-camel service-unit, we will try to stay with camel 1.4 for now.



> Could you try adding a to("log:stream?showBody=false&showBodyType=true") 
> at the beginning and end of your route so we can figure out if any 
> conversion is going on at all?  
> 
> Putting the intercept at the beginning of your route, like you're doing 
> is fine!  Once the stream caching is working property, you should be 
> able to get the body contents any way you like, because you would always 
> be starting from the cached stream (regardless of the type you specify 
> in the getBody()). 
> 

It is getting somewhat mysterious now...

My Routing-config:


>       
> from("jbi:endpoint:http://biz.accelsis.swm/InboundRoutingService/EDIFileInEndpoint";)
>        .intercept(new StreamCachingInterceptor())
>        .process(new DataProcessor(new EdiPreProcessor(),
> DataProcessor.ATTACHMENT_TO_BODY))
>        .process(new DataProcessor(new SyntaxCheckProcessor(),
> DataProcessor.BODY_TO_BODY))
> 
>        //.multicast(new UseLatestAggregationStrategy(), true)
>        .multicast().to("direct:ctrl", "direct:main",
> "log:stream?showBody=false&showBodyType=true");
> 
>        from("direct:ctrl")
>        .intercept(new StreamCachingInterceptor())
>        .process(new DataProcessor(new
> ExtractionProcessor("/envelope/control/data"),   
> DataProcessor.BODY_TO_ATTACHMENT))
>       
> .to("jbi:endpoint:http://biz.accelsis.swm/FileOutService/ContrlOut";);
> 
>        from("direct:main")
>        .intercept(new StreamCachingInterceptor())
>        //.filter().xpath("/envelope/[EMAIL PROTECTED]'1']")
>        .to("jbi:endpoint:http://biz.accelsis.swm/FileOutService/SapOut";);
> 
All jbi:endpoints are jbi file components serving as pollers or senders
respectively.

I was able to build in one logging-endpoint, as you suggested. After
restarting and redeploying, ServiceMix shows that:


> Enter process()....
> Found attachment: org.apache.servicemix.file.content
> MODE: ATTACHMENT_TO_BODY
> Enter process()....
> Found attachment: org.apache.servicemix.file.content
> MODE: BODY_TO_BODY
> Enter process()....
> Found attachment: org.apache.servicemix.file.content
> MODE: BODY_TO_ATTACHMENT
> INFO  - stream                         -
> Exchange[BodyType:org.apache.camel.converter.stream.StreamCacheConverter$StreamSourceCache]
>  
> 
You can see that the multicasted messages contain a
StreamSourceCache-object, so everything seems to be fine here, it does what
it is intended to do. Anyway, sometimes it is a DOMSource... 

But then, if you try to insert a second file.... SMIX output says:


> Enter process()....
> Found attachment: org.apache.servicemix.file.content
> MODE: ATTACHMENT_TO_BODY
> ERROR - DeadLetterChannel              - Failed delivery for exchangeId:
> ID-atnb131/4044-1227108253906/0-0. On delivery attempt: 0 caught: c
> om.ctc.wstx.exc.WstxIOException: Invalid null character in text to output
> com.ctc.wstx.exc.WstxIOException: Invalid null character in text to output
>        at
> com.ctc.wstx.sw.BaseNsStreamWriter.doWriteAttr(BaseNsStreamWriter.java:494)
>        at
> com.ctc.wstx.sw.BaseNsStreamWriter.writeAttribute(BaseNsStreamWriter.java:230)
>        at
> biz.accelsis.swm.processors.impl.EdiPreProcessor.execute(EdiPreProcessor.java:208)
>        at
> biz.accelsis.servicemix.swm.swm_camel_su.processors.DataProcessor.process(DataProcessor.java:54)
>        at
> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.j
> ava:43)
>        at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> .... 

so, it seems as if the first processor fails because the stream of the
message is empty. But why does it run the first time after server restart
and redeploy, and why does it fail thereafter?

Any ideas?

thx in advance
-- 
View this message in context: 
http://www.nabble.com/StreamCachingInterceptor-question-tp20561886s22882p20584577.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to