Thanks, Willem, I'll give that a try. Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
Also I assume I just download this jar and drop it in the deploy directory...correct? Thanks much. --Scott -----Original Message----- From: Willem Jiang [mailto:[email protected]] Sent: Wednesday, January 19, 2011 9:36 PM To: [email protected] Subject: Re: Large(ish) message issue (CXFBC and Camel) On 1/19/11 10:15 PM, Claus Ibsen wrote: > On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<[email protected]> wrote: >> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the >> log messages I included in my message yesterday, it looks like my >> install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log >> message:>>>> 16:52:10,680 | INFO | @qtp-727842206-0 | >> DefaultTypeConverter | l.converter.DefaultTypeConverter 397 | 72 - >> org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Loaded 0 type >> converters in 0.003 seconds.) >> >> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now >> available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB >> 4.3.0-03-00 late last week)? >> >> If not, is there something else that's causing the type converters not to >> get loaded? >> > > Its this bug which was fixed dec-20-2010 > http://fusesource.com/issues/browse/MR-392 > > And -03 hasn't been released yet. Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix? [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar > > >> Thanks for all your help... >> --Scott >> >> -----Original Message----- >> From: Claus Ibsen [mailto:[email protected]] >> Sent: Wednesday, January 19, 2011 5:14 AM >> To: [email protected] >> Subject: Re: Large(ish) message issue (CXFBC and Camel) >> >> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<[email protected]> wrote: >>> Fuse ESB 4.3.0-03-00 is what I'm using...it contains Camel 2.4. If I >>> understand Claus correctly, I need Camel 2.6... >>> >> >> No the bug is fixed in FUSE Camel 2.4. (latest version of FUSE 2.4 version). >> At Apache the bug is only to be fixed in the upcoming Camel 2.6 release. >> >> >>> -----Original Message----- >>> From: Willem Jiang [mailto:[email protected]] >>> Sent: Wednesday, January 19, 2011 2:02 AM >>> To: [email protected] >>> Subject: Re: Large(ish) message issue (CXFBC and Camel) >>> >>> Why don't you just download the Fuse ESB 4.3.0-fuse-03-00? >>> You don't need to build the component yourself. >>> >>> On 1/19/11 10:34 AM, Scott Came wrote: >>>> I've actually succeeded in building the 2011.01-SNAPSHOT version of >>>> servicemix-camel that's in SVN. I have the component .jar and installer >>>> .zip in my local maven repository now. >>>> >>>> Any reason why I shouldn't be able to install that in >>>> servicemix-4.3.0-fuse-03-00? Do I just drop the zip file in the deploy >>>> directory? Do I need to be worried about conflicts with the currently >>>> installed version of Camel (i.e., should I uninstall)? >>>> >>>> Excuse the newbie questions...is there a way to deploy this snapshot via >>>> the features mechanism? >>>> >>>> Anyway, if I can get this going I'd be happy to testdrive the >>>> 2011.01-SNAPSHOT build of servicemix-camel... >>>> >>>> Thanks. >>>> --Scott >>>> >>>> -----Original Message----- >>>> From: Scott Came [mailto:[email protected]] >>>> Sent: Tuesday, January 18, 2011 12:33 PM >>>> To: [email protected] >>>> Subject: RE: Large(ish) message issue (CXFBC and Camel) >>>> >>>> Thanks, Claus. Is there anything I can do in the meantime? Is the fix in >>>> a current Camel build? If so, are there docs on how to update the Camel >>>> components in SM? >>>> >>>> --Scott >>>> >>>> -----Original Message----- >>>> From: Claus Ibsen [mailto:[email protected]] >>>> Sent: Tuesday, January 18, 2011 7:56 AM >>>> To: [email protected] >>>> Subject: Re: Large(ish) message issue (CXFBC and Camel) >>>> >>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<[email protected]> >>>> wrote: >>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<[email protected]> >>>>> wrote: >>>>>> Thanks, Claus. >>>>>> >>>>>> I grepped my logs for AnnotationTypeConverterLoader and see a line like >>>>>> this: >>>>>> >>>>>> 16:52:10,678 | INFO | @qtp-727842206-0 | >>>>>> AnnotationTypeConverterLoader | er.AnnotationTypeConverterLoader >>>>>> 66 | 72 - org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Found >>>>>> 3 packages with 0 @Converter classes to load >>>>>> >>>>>> Grepped for DefaultTypeConverter and see this: >>>>>> >>>>>> 16:52:10,680 | INFO | @qtp-727842206-0 | DefaultTypeConverter >>>>>> | l.converter.DefaultTypeConverter 397 | 72 - >>>>>> org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Loaded 0 type >>>>>> converters in 0.003 seconds >>>>>> >>>>>> I'm guessing that's not good. I am running the current release version >>>>>> of FUSE ESB (apache-servicemix-4.3.0-fuse-03-00). I'm not sure what >>>>>> version of Camel is included, but I haven't done anything to update >>>>>> Camel outside of the stock FUSE ESB distro. It looks from the above log >>>>>> message like it's Camel 2.4.0.fuse-02-00. >>>>>> >>>>> >>>>> Yeah it should be fixed in FUSE ESB 4.3.1 which includes Camel >>>>> 2.4.0-fuse-03-00 which has the fix. >>>>> >>>> >>>> Correction, that would be the next FUSE ESB 4.3.0 release. >>>> >>>> I think there is a ESB 4.3.1 planned later this month/next month which >>>> will ship with Camel 2.6 (currently in progress). >>>> >>>> >>>>> From Camel 2.6 onwards we actually now will throw an exception >>>>> on starting Camel if this situation happens again. >>>>> Then it should be much easier for end user to spot something is wrong. >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks for your help. >>>>>> --Scott >>>>>> >>>>>> -----Original Message----- >>>>>> From: Claus Ibsen [mailto:[email protected]] >>>>>> Sent: Monday, January 17, 2011 10:05 PM >>>>>> To: [email protected] >>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel) >>>>>> >>>>>> What versions of the products are you using? SMX / Camel? >>>>>> And how do you startup the SMX container? >>>>>> >>>>>> I think there was a bug when using JBI with SMX 4.x that could lead to >>>>>> Camel not being able to load type converters on startup (race condition >>>>>> when using OSGi). This should be fixed in upcoming Apache SMX 4.3 >>>>>> release and already in the latest FUSE ESB release. >>>>>> >>>>>> You should see something like this at INFO level logged by Camel >>>>>> on startup (requires Camel 2.3 or better) >>>>>> >>>>>> 2011-01-18 07:05:00,519 [main ] INFO >>>>>> AnnotationTypeConverterLoader - Found 3 packages with 19 >>>>>> @Converter classes to load >>>>>> 2011-01-18 07:05:00,567 [main ] INFO >>>>>> DefaultTypeConverter >>>>>> - Loaded 150 type converters in 1.038 seconds >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 18, 2011 at 5:42 AM, Scott Came<[email protected]> >>>>>> wrote: >>>>>>> Hi Freeman, thanks for the suggestion. >>>>>>> >>>>>>> I tried that and am seeing the same results. After consulting the >>>>>>> Camel documentation about stream caching at >>>>>>> http://camel.apache.org/stream-caching.html I tried various flavors of >>>>>>> specifying it (e.g., specifying streamCache="true" on camelContext and >>>>>>> streamCaching="true" and streamCache="true" on route)...none of those >>>>>>> helped. >>>>>>> >>>>>>> I also tried removing the<to> element for the log message, and that >>>>>>> didn't help either. >>>>>>> >>>>>>> It's like in the case of both<to uri="log..."> and<to uri="file..."> >>>>>>> the stream from the jbi: endpoint is getting cut off after 1000-2000 >>>>>>> bytes. Very strange. >>>>>>> >>>>>>> I set the log level to DEBUG, and I get a big nested stack trace at the >>>>>>> expected place, with this as the last exception listed: >>>>>>> >>>>>>> Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected end of >>>>>>> input block in start tag >>>>>>> at [row,col {unknown-source}]: [51,20] >>>>>>> at >>>>>>> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOB(StreamScanner.java: >>>>>>> 69 >>>>>>> 6) >>>>>>> at >>>>>>> com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner. >>>>>>> ja >>>>>>> v >>>>>>> a >>>>>>> :1 >>>>>>> 062) >>>>>>> at >>>>>>> com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner. >>>>>>> j >>>>>>> av >>>>>>> a:807) >>>>>>> at >>>>>>> com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader. >>>>>>> ja >>>>>>> va:2892) >>>>>>> at >>>>>>> com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java: >>>>>>> 2783) >>>>>>> at >>>>>>> com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:10 >>>>>>> 48 >>>>>>> ) >>>>>>> at >>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(F >>>>>>> ra >>>>>>> g >>>>>>> m >>>>>>> en >>>>>>> tStreamReader.java:68) >>>>>>> at >>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(Sta >>>>>>> xJ >>>>>>> b >>>>>>> i >>>>>>> Wr >>>>>>> apper.java:166) >>>>>>> at >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource.parse(StaxSource.java: >>>>>>> 116) >>>>>>> ... 54 more >>>>>>> >>>>>>> Incidentally, the first exception (top of the stack) is this: >>>>>>> >>>>>>> org.apache.camel.InvalidPayloadException: No body available of type: >>>>>>> java.lang.String but has value: >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207 of type: >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource on: Message: >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207. Caused by: >>>>>>> No type converter available to convert from type: >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource to the required type: >>>>>>> java.lang.String with value >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207. >>>>>>> Exchange[Message: >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207]. Caused by: >>>>>>> [org.apache.camel.NoTypeConversionAvailableException - No type >>>>>>> converter available to convert from type: >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource to the required type: >>>>>>> java.lang.String with value >>>>>>> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207] >>>>>>> at >>>>>>> org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSup >>>>>>> po >>>>>>> r >>>>>>> t >>>>>>> .j >>>>>>> ava:103) >>>>>>> at >>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertB >>>>>>> od >>>>>>> y >>>>>>> P >>>>>>> ro >>>>>>> cessor.java:57) >>>>>>> at >>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Proc >>>>>>> es >>>>>>> s >>>>>>> o >>>>>>> rT >>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50) >>>>>>> at >>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso >>>>>>> rH >>>>>>> e >>>>>>> l >>>>>>> pe >>>>>>> r.java:70) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De >>>>>>> le >>>>>>> g >>>>>>> a >>>>>>> te >>>>>>> AsyncProcessor.java:98) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega >>>>>>> te >>>>>>> A >>>>>>> s >>>>>>> yn >>>>>>> cProcessor.java:89) >>>>>>> at >>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins >>>>>>> tr >>>>>>> u >>>>>>> m >>>>>>> en >>>>>>> tationProcessor.java:68) >>>>>>> at >>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso >>>>>>> rH >>>>>>> e >>>>>>> l >>>>>>> pe >>>>>>> r.java:70) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De >>>>>>> le >>>>>>> g >>>>>>> a >>>>>>> te >>>>>>> AsyncProcessor.java:98) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega >>>>>>> te >>>>>>> A >>>>>>> s >>>>>>> yn >>>>>>> cProcessor.java:89) >>>>>>> at >>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process( >>>>>>> Tr >>>>>>> a >>>>>>> c >>>>>>> eI >>>>>>> nterceptor.java:99) >>>>>>> at >>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso >>>>>>> rH >>>>>>> e >>>>>>> l >>>>>>> pe >>>>>>> r.java:70) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De >>>>>>> le >>>>>>> g >>>>>>> a >>>>>>> te >>>>>>> AsyncProcessor.java:98) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega >>>>>>> te >>>>>>> A >>>>>>> s >>>>>>> yn >>>>>>> cProcessor.java:89) >>>>>>> at >>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins >>>>>>> tr >>>>>>> u >>>>>>> m >>>>>>> en >>>>>>> tationProcessor.java:68) >>>>>>> at >>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso >>>>>>> rH >>>>>>> e >>>>>>> l >>>>>>> pe >>>>>>> r.java:70) >>>>>>> at >>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHa >>>>>>> nd >>>>>>> l >>>>>>> e >>>>>>> r( >>>>>>> RedeliveryErrorHandler.java:290) >>>>>>> at >>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redeli >>>>>>> ve >>>>>>> r >>>>>>> y >>>>>>> Er >>>>>>> rorHandler.java:202) >>>>>>> at >>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java: >>>>>>> 256) >>>>>>> at >>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso >>>>>>> rH >>>>>>> e >>>>>>> l >>>>>>> pe >>>>>>> r.java:70) >>>>>>> at >>>>>>> org.apache.camel.processor.Pipeline.process(Pipeline.java:143) >>>>>>> at >>>>>>> org.apache.camel.processor.Pipeline.process(Pipeline.java:78) >>>>>>> at >>>>>>> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWor >>>>>>> kP >>>>>>> r >>>>>>> o >>>>>>> ce >>>>>>> ssor.java:99) >>>>>>> at >>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso >>>>>>> rH >>>>>>> e >>>>>>> l >>>>>>> pe >>>>>>> r.java:70) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De >>>>>>> le >>>>>>> g >>>>>>> a >>>>>>> te >>>>>>> AsyncProcessor.java:98) >>>>>>> at >>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega >>>>>>> te >>>>>>> A >>>>>>> s >>>>>>> yn >>>>>>> cProcessor.java:89) >>>>>>> at >>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins >>>>>>> tr >>>>>>> u >>>>>>> m >>>>>>> en >>>>>>> tationProcessor.java:68) >>>>>>> at >>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelPr >>>>>>> ov >>>>>>> i >>>>>>> d >>>>>>> er >>>>>>> Endpoint.java:109) >>>>>>> at >>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassL >>>>>>> oa >>>>>>> d >>>>>>> e >>>>>>> r( >>>>>>> JbiBinding.java:116) >>>>>>> at >>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActivePr >>>>>>> ov >>>>>>> i >>>>>>> d >>>>>>> er >>>>>>> Exchange(CamelProviderEndpoint.java:107) >>>>>>> at >>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelP >>>>>>> ro >>>>>>> v >>>>>>> i >>>>>>> de >>>>>>> rEndpoint.java:85) >>>>>>> at >>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncB >>>>>>> as >>>>>>> e >>>>>>> L >>>>>>> if >>>>>>> eCycle.java:651) >>>>>>> at >>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange( >>>>>>> As >>>>>>> y >>>>>>> n >>>>>>> cB >>>>>>> aseLifeCycle.java:606) >>>>>>> at >>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeI >>>>>>> nT >>>>>>> x >>>>>>> ( >>>>>>> As >>>>>>> yncBaseLifeCycle.java:501) >>>>>>> at >>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseL >>>>>>> if >>>>>>> e >>>>>>> C >>>>>>> yc >>>>>>> le.java:370) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoo >>>>>>> lE >>>>>>> x >>>>>>> e >>>>>>> cu >>>>>>> tor.java:886) >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. >>>>>>> java:908) >>>>>>> at java.lang.Thread.run(Thread.java:680) >>>>>>> >>>>>>> Any other ideas? >>>>>>> >>>>>>> Thanks. >>>>>>> --Scott >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Freeman Fang [mailto:[email protected]] >>>>>>> Sent: Monday, January 17, 2011 7:08 PM >>>>>>> To: [email protected] >>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel) >>>>>>> >>>>>>> >>>>>>> On 2011-1-18, at 上午10:41, Scott Came wrote: >>>>>>> >>>>>>>> I am seeing some strange behavior when using Camel to route >>>>>>>> from a JBI endpoint (cxfbc) to a file using the Camel file component. >>>>>>>> >>>>>>>> Here is the scenario. >>>>>>>> >>>>>>>> I have created a JBI CXFBC service unit with WSDL. I have also >>>>>>>> created a Camel service unit, with a very simple route: it >>>>>>>> routes from the CXFBC endpoint to a file with a route that looks like >>>>>>>> this: >>>>>>>> >>>>>>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/ >>>>>>>> spring"> >>>>>>>> <route> >>>>>>>> <from >>>>>>>> uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encount >>>>>>>> er >>>>>>>> - r ou t er/RouterService/RouterServiceEndpoint >>>>>>>> "/> >>>>>>>> <to >>>>>>>> uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/> >>>>>>>> <convertBodyTo type="java.lang.String"/> >>>>>>>> <to uri="file:/Users/scott/Desktop/router-output"/> >>>>>>>> </route> >>>>>>>> </camelContext> >>>>>>>> >>>>>>>> I bundle these to SUs into an SA and deploy. Everything deploys fine. >>>>>>>> >>>>>>>> I then use SOAPUI to send test messages. >>>>>>>> >>>>>>>> If I send a very small message...say, no bigger than a couple >>>>>>>> hundred bytes, to the RouterServiceEndpoint, everything works fine. >>>>>>>> I see the log message in the log, and the file gets written to >>>>>>>> my router-output directory. >>>>>>>> >>>>>>>> However, when I increase the message size beyond a certain >>>>>>>> point (not sure exactly where it is...somewhere around >>>>>>>> 2000-3000 bytes) I start getting messages like: >>>>>>>> >>>>>>>> Unexpected end of input block in start tag at [row,col >>>>>>>> {unknown- >>>>>>>> source}]: [51,20] >>>>>>>> >>>>>>>> The underlying exception seems to be a >>>>>>>> com.ctc.wstx.exc.WstcEOFException. >>>>>>>> >>>>>>>> If I try subsequent invocations of the service, I get a similar >>>>>>>> error, though the referenced place in the stream is often a >>>>>>>> little different (e.g., [51, 25] or [55, 10]). So it seems >>>>>>>> like the parser is getting to a different place in the stream each >>>>>>>> time before it fails. >>>>>>>> >>>>>>>> I have put TCPMon in the middle and verified that the entire >>>>>>>> message is getting to the server, although the server side is >>>>>>>> not closing the connection when the exception occurs. >>>>>>>> >>>>>>>> I am 100% sure the content being sent is valid XML. >>>>>>>> >>>>>>>> Interestingly, if I take out the<to> part of the route to the >>>>>>>> file component, everything works fine...I get the simple log >>>>>>>> message (note that I am not logging the body content), and the >>>>>>>> connection closes in TCPMon. However, if I switch to logging >>>>>>>> the body content (i.e., take off the ?showBody=false option), I >>>>>>>> get similar errors as when I try to write out the file. >>>>>>> This looks like a stream already get consumed issue for me, how >>>>>>> about you just >>>>>>> >>>>>>> How about you just change your router like<camelContext id="camel" >>>>>>> xmlns="http://camel.apache.org/schema/spring";> >>>>>>> <route streamCache="true"> >>>>>>> <from >>>>>>> uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounte >>>>>>> r- r o ut er/RouterService/RouterServiceEndpoint >>>>>>> "/> >>>>>>> <to >>>>>>> uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/> >>>>>>> <convertBodyTo type="java.lang.String"/> >>>>>>> <to uri="file:/Users/scott/Desktop/router-output"/> >>>>>>> </route> >>>>>>> </camelContext> >>>>>>> >>>>>>> Freeman >>>>>>> >>>>>>>> I have tried taking out the<convertBodyTo...> element, but that >>>>>>>> results in a different exception...something about no >>>>>>>> appropriate converter being found. >>>>>>>> >>>>>>>> It would be somewhat difficult for me to attach a full example, >>>>>>>> as the content of the large message is somewhat >>>>>>>> sensitive/proprietary, but I could do that if I absolutely >>>>>>>> needed to. I'm hoping there is some simple configuration >>>>>>>> setting I need to tweak to handle bigger messages (though a 2K >>>>>>>> or 3K message is by no means large...) >>>>>>>> >>>>>>>> Thanks for any help you can offer. >>>>>>>> >>>>>>>> --Scott >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Freeman Fang >>>>>>> >>>>>>> ------------------------ >>>>>>> >>>>>>> FuseSource: http://fusesource.com >>>>>>> blog: http://freemanfang.blogspot.com >>>>>>> twitter: http://twitter.com/freemanfang Apache >>>>>>> Servicemix:http://servicemix.apache.org >>>>>>> Apache Cxf: http://cxf.apache.org Apache Karaf: >>>>>>> http://karaf.apache.org Apache Felix: >>>>>>> http://felix.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Claus Ibsen >>>>>> ----------------- >>>>>> FuseSource >>>>>> Email: [email protected] >>>>>> Web: http://fusesource.com >>>>>> Twitter: davsclaus >>>>>> Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: >>>>>> http://www.manning.com/ibsen/ >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Claus Ibsen >>>>> ----------------- >>>>> FuseSource >>>>> Email: [email protected] >>>>> Web: http://fusesource.com >>>>> Twitter: davsclaus >>>>> Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: >>>>> http://www.manning.com/ibsen/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> FuseSource >>>> Email: [email protected] >>>> Web: http://fusesource.com >>>> Twitter: davsclaus >>>> Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: >>>> http://www.manning.com/ibsen/ >>>> >>> >>> >>> -- >>> Willem >>> ---------------------------------- >>> FuseSource >>> Web: http://www.fusesource.com >>> Blog: http://willemjiang.blogspot.com (English) >>> http://jnn.javaeye.com (Chinese) >>> Twitter: willemjiang >>> >>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: [email protected] >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> >> > > > -- Willem ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
