Hi Claus, In our recent tests, we introduced a TraceInterceptor stategy, and all of a sudden it worked like a charm! (it sent the response back to the client). Nothing else was changed. We couldn't believe what was going on, so we tried removing it and putting it back again several times with exactly the same results! Why do you think this is?
Is this is related to the servicemix-camel component? Any issues that come to mind which have been resolved since the 2009.01 version, that could justify this behaviour? Thanks Raúl. Claus Ibsen-2 wrote: > > On Thu, Feb 18, 2010 at 12:38 PM, raulvk.soa <[email protected]> wrote: >> >> Any clues on what could be happening? >> >> >> raulvk.soa wrote: >>> >>> Hi, >>> >>> We are having trouble migrating from Camel 1.4.0 (bundled with >>> ServiceMix >>> 3.2.2) to Camel 1.6.0 (SMix 3.3.1). Our only difficulty is with the >>> exception handling. >>> >>> Before calling a Camel validator, we have the following exception >>> handling >>> logic: >>> >>> onException(ValidationException.class).handled(false) >>> >>> .setProperty("errorCode").constant("A001").setProperty("description").constant("Validation >>> Error") >>> .setProperty("system").constant("ServiceMix") >>> >>> .to("log:ReceiveOrders.ValidationError?level=WARN&showAll=true") >>> .convertBodyTo(String.class).to("xslt:createExceptionMessageForClient.xsl").convertBodyTo(DOMSource.class) >>> >>> .to("log:ReceiveOrders.ReturnedMessage?level=WARN&showAll=true") >>> >>> .to("direct:transformResponse").convertBodyTo(DOMSource.class) >>> >>> .to("direct:wrapResponse").convertBodyTo(DOMSource.class) >>> >>> .to("log:ReceiveOrders.RouteFinished?level=WARN&showAll=true"); >>> >>> We need the message to be sent back on to the JBI Bus (the route starts >>> with a from("jbi:...") endpoint), but it is being sucked up by the >>> DeadLetterQueue, and the JBI client times out. With Camel 1.4.0 it >>> worked >>> like a charm (of course, we had no "handled" instruction because it >>> wasn't >>> supported back then), but now we can't get it to unwind the stack and >>> return the response to the client. >>> >>> There is no errorHandler declared, only another >>> onException(Exception.class), which handles all unmanaged exceptions. >>> >>> Having tried numerous configurations to make it work, we resort to the >>> wonderful & active Camel forum to shed some light on this case. Some of >>> the combinations we have attempted with no luck are: >>> >>> 1. errorHandler(noErrorHandler()) >>> 2. putting a processor at the end to copy the in message to the out >>> message >>> 3. encapsulating all the routing logic into another direct: route, >>> and >>> calling that from within the onException. >>> 4. tuning the handled parameter >>> 5. putting transform() at the end. >>> >>> Can someone give us a hand? >>> > > Have you tried with the latest SMX 3.3 code? eg 3.3-SNAPSHOT > > Frankly Apache ServiceMix is not very often released and I would > suggest to consider using the FUSE based distributions. > We release far more often SMX versions. > > For example you can see the release notes which has the latest release > from about 1 month ago. > http://fusesource.com/wiki/display/ProdInfo/FUSE+ESB+v3.3+Release+Notes > > I know there are fixed in there for servicemix-camel which improves > the integration between the two of them, also in relation to error > handling. > You can check the release notes yourself and see. > > > > >>> Many thanks! >>> Raul. >>> >> >> -- >> View this message in context: >> http://old.nabble.com/onException-not-returning-a-response-tp27629416p27637394.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > > -- View this message in context: http://old.nabble.com/onException-not-returning-a-response-tp27629416p27647741.html Sent from the Camel - Users mailing list archive at Nabble.com.
