When looking at the
CamelJbiEnpoint<http://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-camel/trunk/src/main/java/org/apache/servicemix/camel/CamelJbiEndpoint.java>class
it seems that effectively camel does not look at exchange status
in method "handleActiveProviderExchange()". It simply send message to camel
processor and send the message back to NMR.
FYI I'm using servicemix-camel-3.2.2-SNAPSHOT and camel-core 1.4-SNAPSHOT
On Tue, Jul 22, 2008 at 10:42 AM, Gert Vanthienen <[EMAIL PROTECTED]>
wrote:
> Manuel,
>
> If this is the MessageExchange coming back from the Camel endpoint after
> you have explicitly thrown an exception to force the error, I would suggest
> you raise a JIRA for this. Looks like the Camel component doesn't forward
> the Fault message then.
>
>
> Regards,
>
> Gert
>
> Manuel EVENO wrote:
>
>> I've already set the log4j debug level for servicemix and the log file
>> attached in my previous mail show
>> the message echange info. Here it is :
>>
>> *12:34:37,412 | DEBUG | pool-flow.seda.servicemix-camel-thread-3 |
>> SedaQueue | .jbi.nmr.flow.seda.SedaQueue$1 132 |
>> [EMAIL PROTECTED] dequeued
>> exchange: InOut[
>> id: ID:10.133.251.75-11b452c884b-3:0
>> status: Done
>> role: provider
>> service: {http://hello.samples.sofinco.com}HelloServiceRoute
>> endpoint: camel10-133-251-75-11b452c884b-5-0
>> operation: {http://hello.samples.sofinco.com}sayHello
>> in: <?xml version="1.0" encoding="UTF-8"?><jbi:message xmlns:jbi="
>> http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper"; xmlns:msg="
>> http://hello.samples.sofinco.com"; name="sayHello" type="msg:sayHello"
>> version="1.0"><jbi:part><ns1:sayHello xmlns:ns1="
>> http://hello.samples.sofinco.com";><arg0 xmlns:ns2="
>> http://hello.samples.sofinco.com
>> ">Manuel</arg0></ns1:sayHello></jbi:part></jbi:message>
>> ]*
>>
>> Status = Done and no out or fault message :(
>>
>>
>> On Tue, Jul 22, 2008 at 10:14 AM, Gert Vanthienen <
>> [EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Manuel,
>>>
>>> Could you set DEBUG logging in ServiceMix, so you could take a look at
>>> the
>>> message exchanges that go through the ESB? Especially, what does the
>>> MessageExchange that goes back to your CXF BC endpoint look like? Does
>>> it
>>> have a DONE or ERROR status?
>>>
>>> Gert
>>>
>>>
>>> Manuel EVENO wrote:
>>>
>>>
>>>
>>>> I'm stuck with that.
>>>>
>>>> Anyone with any clue ? ;)
>>>>
>>>>
>>>> On Mon, Jul 21, 2008 at 2:06 PM, Manuel EVENO <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Maybe, I've done something wrong but now I don't have any response on
>>>>> error.
>>>>> Here is the log for the client (using CXF), the response payload is
>>>>> empty
>>>>> and there's no soap fault.
>>>>>
>>>>> *INFO: Outbound Message
>>>>> ---------------------------
>>>>> Encoding: UTF-8
>>>>> Headers: {SOAPAction=[""], Accept=[*]}
>>>>> Messages:
>>>>> Payload: <soap:Envelope xmlns:soap="
>>>>> http://schemas.xmlsoap.org/soap/envelope/";><**soap:Body><ns1:sayHello
>>>>> xmlns:ns1="http://hello.samples.sofinco.com";><arg0 xmlns:ns2="
>>>>> http://hello.samples.sofinco.com
>>>>> ">Manuel</**arg0></ns1:sayHello></soap:**
>>>>> Body></soap:Envelope>
>>>>> ------------------------------**--------
>>>>> 21 juil. 2008 11:22:51
>>>>> org.apache.cxf.interceptor.**LoggingInInterceptor
>>>>> logging
>>>>> INFO: Inbound Message
>>>>> ----------------------------
>>>>> Encoding: UTF-8
>>>>> Headers: {transfer-encoding=[chunked], Server=[Jetty(6.1.5)]}
>>>>> Messages:
>>>>> Message:
>>>>>
>>>>> Payload:
>>>>> ------------------------------**--------
>>>>> 21 juil. 2008 11:22:51 org.apache.cxf.phase.**PhaseInterceptorChain
>>>>> doIntercept
>>>>> INFO: Interceptor has thrown exception, unwinding now
>>>>> org.apache.cxf.binding.soap.**SoapFault: Error reading XMLStreamReader.
>>>>> at
>>>>> org.apache.cxf.binding.soap.**interceptor.**ReadHeadersInterceptor.
>>>>> **handleMessage(**ReadHeadersInterceptor.java:**183)
>>>>> at
>>>>> org.apache.cxf.binding.soap.**interceptor.**ReadHeadersInterceptor.
>>>>> **handleMessage(**ReadHeadersInterceptor.java:**54)
>>>>> at org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
>>>>> PhaseInterceptorChain.java:**221)
>>>>> at org.apache.cxf.endpoint.**ClientImpl.onMessage(**
>>>>> ClientImpl.java:449)
>>>>> at
>>>>> org.apache.cxf.transport.http.**HTTPConduit$**WrappedOutputStream.*
>>>>> *handleResponse(HTTPConduit.**java:1996)
>>>>> at org.apache.cxf.transport.http.**HTTPConduit$**
>>>>> WrappedOutputStream.close(**HTTPConduit.java:1832)
>>>>> at org.apache.cxf.io.**CacheAndWriteOutputStream.**postClose(**
>>>>> CacheAndWriteOutputStream.**java:47)
>>>>> at org.apache.cxf.io.**CachedOutputStream.close(**
>>>>> CachedOutputStream.java:159)
>>>>> at org.apache.cxf.transport.**AbstractConduit.close(**
>>>>> AbstractConduit.java:66)
>>>>> at org.apache.cxf.transport.http.**HTTPConduit.close(HTTPConduit.**
>>>>> java:591)
>>>>> at org.apache.cxf.interceptor.**MessageSenderInterceptor$**
>>>>> MessageSenderEndingInterceptor**.handleMessage(**
>>>>> MessageSenderInterceptor.java:**62)
>>>>> at org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
>>>>> PhaseInterceptorChain.java:**221)
>>>>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:296)
>>>>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:242)
>>>>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:200)
>>>>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:220)
>>>>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:206)
>>>>> at com.sofinco.samples.hello.**HelloServiceClient.sayHello(**
>>>>> HelloServiceClient.java:29)
>>>>> at com.sofinco.samples.hello.**HelloServiceClientTest.**
>>>>> testSayHelloESBWithJaxWsProxy(**HelloServiceClientTest.java:**29)
>>>>> at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
>>>>> at sun.reflect.**NativeMethodAccessorImpl.**invoke(**
>>>>> NativeMethodAccessorImpl.java:**39)
>>>>> at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
>>>>> DelegatingMethodAccessorImpl.**java:25)
>>>>> at java.lang.reflect.Method.**invoke(Method.java:597)
>>>>> at org.junit.internal.runners.**TestMethod.invoke(TestMethod.**
>>>>> java:59)
>>>>> at org.junit.internal.runners.**MethodRoadie.runTestMethod(**
>>>>> MethodRoadie.java:98)
>>>>> at org.junit.internal.runners.**MethodRoadie$2.run(**
>>>>> MethodRoadie.java:79)
>>>>> at org.junit.internal.runners.**MethodRoadie.**
>>>>> runBeforesThenTestThenAfters(**MethodRoadie.java:87)
>>>>> at org.junit.internal.runners.**MethodRoadie.runTest(**
>>>>> MethodRoadie.java:77)
>>>>> at org.junit.internal.runners.**MethodRoadie.run(MethodRoadie.**
>>>>> java:42)
>>>>> at
>>>>> org.junit.internal.runners.**JUnit4ClassRunner.**invokeTestMethod(*
>>>>> *JUnit4ClassRunner.java:88)
>>>>> at org.junit.internal.runners.**JUnit4ClassRunner.runMethods(**
>>>>> JUnit4ClassRunner.java:51)
>>>>> at org.junit.internal.runners.**JUnit4ClassRunner$1.run(**
>>>>> JUnit4ClassRunner.java:44)
>>>>> at org.junit.internal.runners.**ClassRoadie.runUnprotected(**
>>>>> ClassRoadie.java:27)
>>>>> at org.junit.internal.runners.**ClassRoadie.runProtected(**
>>>>> ClassRoadie.java:37)
>>>>> at org.junit.internal.runners.**JUnit4ClassRunner.run(**
>>>>> JUnit4ClassRunner.java:42)
>>>>> at
>>>>> org.eclipse.jdt.internal.**junit4.runner.**JUnit4TestReference.run(
>>>>> **JUnit4TestReference.java:45)
>>>>> at org.eclipse.jdt.internal.**junit.runner.TestExecution.**
>>>>> run(TestExecution.java:38)
>>>>> at org.eclipse.jdt.internal.**junit.runner.RemoteTestRunner.**
>>>>> runTests(RemoteTestRunner.**java:460)
>>>>> at org.eclipse.jdt.internal.**junit.runner.RemoteTestRunner.**
>>>>> runTests(RemoteTestRunner.**java:673)
>>>>> at org.eclipse.jdt.internal.**junit.runner.RemoteTestRunner.**
>>>>> run(RemoteTestRunner.java:386)
>>>>> at org.eclipse.jdt.internal.**junit.runner.RemoteTestRunner.**
>>>>> main(RemoteTestRunner.java:**196)
>>>>> Caused by: com.ctc.wstx.exc.**WstxEOFException: Unexpected EOF in
>>>>> prolog
>>>>> at [row,col {unknown-source}]: [1,0]
>>>>> at com.ctc.wstx.sr.StreamScanner.**throwUnexpectedEOF(**
>>>>> StreamScanner.java:661)
>>>>> at com.ctc.wstx.sr.**BasicStreamReader.handleEOF(**
>>>>> BasicStreamReader.java:2134)
>>>>> at com.ctc.wstx.sr.**BasicStreamReader.**nextFromProlog(**
>>>>> BasicStreamReader.java:2040)
>>>>> at com.ctc.wstx.sr.**BasicStreamReader.next(**
>>>>> BasicStreamReader.java:1069)
>>>>> at com.ctc.wstx.sr.**BasicStreamReader.nextTag(**
>>>>> BasicStreamReader.java:1095)
>>>>> at
>>>>> org.apache.cxf.binding.soap.**interceptor.**ReadHeadersInterceptor.
>>>>> **handleMessage(**ReadHeadersInterceptor.java:**83)
>>>>> ... 40 more
>>>>> *
>>>>> I found a log entry telling Camel called my processor but it seems to
>>>>> do
>>>>> nothing :
>>>>>
>>>>> *11:40:53,280 | ERROR | pool-flow.seda.servicemix-camel-thread-3 |
>>>>> DeadLetterChannel | .apache.camel.processor.Logger 152 | Failed
>>>>> delivery for exchangeId: ID-PSP0020/4119-1216629810312/0-8. Handled by
>>>>> the
>>>>> failure processor: [EMAIL PROTECTED]
>>>>> *
>>>>> Here is the camel config (Java) :
>>>>>
>>>>> * DeadLetterChannelBuilder deadLetterChannel =
>>>>> deadLetterChannel();
>>>>> deadLetterChannel.setRedeliveryPolicy(redeliveryPolicy);
>>>>> deadLetterChannel.setDefaultDeadLetterEndpoint(new
>>>>> ErrorProcessor());
>>>>> errorHandler(deadLetterChannel);
>>>>> *
>>>>> And the ErrorProcessor class :
>>>>>
>>>>> *public final class ErrorProcessor implements Processor {
>>>>> public void process(Exchange exchange) throws Exception {
>>>>> throw new CamelExchangeException("Message redelivery failed",
>>>>> exchange);
>>>>> }
>>>>> }
>>>>> *
>>>>>
>>>>> I've also tried another ErrorProcessor :
>>>>>
>>>>> *public final class ErrorProcessor implements Processor {
>>>>> private static final Logger logger =
>>>>> Logger.getLogger(ErrorProcessor.class);
>>>>> public void process(Exchange exchange) throws Exception {
>>>>> Throwable exception = (Throwable)
>>>>> exchange.getProperty(DeadLetterChannel.EXCEPTION_CAUSE_PROPERTY);
>>>>> if (exception != null) {
>>>>> exchange.setException(exception);
>>>>> } else {
>>>>> DeadLetterChannel.restoreExceptionOnExchange(exchange);
>>>>> }
>>>>> if (exchange.getException() == null) {
>>>>> exchange.getFault(true).setBody(new
>>>>> CamelExchangeException("Message redelivery failed", exchange));
>>>>> }
>>>>> logger.info("Setting exchange exception to
>>>>> "+exchange.getException());
>>>>> logger.info("Exchange.isFailed()="+exchange.isFailed());
>>>>> }
>>>>> }
>>>>> *
>>>>>
>>>>> Which imply the same behavior ...
>>>>>
>>>>> (See the complete servicemix log file attached)
>>>>>
>>>>> Any clue ?
>>>>> Manuel
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2008 at 10:37 AM, Gert Vanthienen <
>>>>> [EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Manuel,
>>>>>>
>>>>>> The trick with the Processor should work as well. Are you
>>>>>> experiencing
>>>>>> any
>>>>>> problems with it?
>>>>>>
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>> Manuel EVENO wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks Gert for these information !
>>>>>>>
>>>>>>> I foudn the way to configure the deadLetterChannel Behavior but I
>>>>>>> stil
>>>>>>> can't
>>>>>>> configure the final exception behavior.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> If you want the DeadLetterChannel handling to fail (instead of log)
>>>>>>>>
>>>>>>>>
>>>>>>>>> after
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> the redelivery attempts, you can end the deadLetterChannel()
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> clause in your RouteBuilder with .throwFault() to force the
>>>>>>>> exception.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The .throwFault() method seems to be part of the ProcessorType class
>>>>>>>>
>>>>>>>>
>>>>>>> but
>>>>>>> the
>>>>>>> ErrorHandlerBuilderSupport (and DeadLetterChannelBuilder) class
>>>>>>> doesn't
>>>>>>> have
>>>>>>> such method.
>>>>>>> Guided by your hint (specially reading your sentence "instead of
>>>>>>> log"),
>>>>>>> I've
>>>>>>> looked for the log step and found the defaultDeadLetterEndpointUri
>>>>>>> which
>>>>>>> points to log:org.apache.camel.DeadLetterChannel?level=error";
>>>>>>>
>>>>>>> So if I change the default dead letter endpoint to the following,
>>>>>>> does
>>>>>>> this
>>>>>>> make the exception trick ?
>>>>>>>
>>>>>>> deadLetterChannel.setDefaultDeadLetterEndpoint(new Processor()
>>>>>>> {
>>>>>>> public void process(Exchange exchange) throws Exception {
>>>>>>> throw new CamelExchangeException("All message
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> redeliveries
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> failed", exchange);
>>>>>>> }
>>>>>>> });
>>>>>>>
>>>>>>> Manuel
>>>>>>>
>>>>>>> On Mon, Jul 21, 2008 at 7:57 AM, Gert Vanthienen
>>>>>>> <[EMAIL PROTECTED]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Manuel,
>>>>>>>>
>>>>>>>> If you do not configure any specific ErrorHandler in your Camel
>>>>>>>> RouteBuilder, Camel will default to using a DeadLetterChannel
>>>>>>>> handler
>>>>>>>> with
>>>>>>>> 5? re-delivery attempts and logging an error after these delivery
>>>>>>>> attempts.
>>>>>>>> From a JBI perspective, by logging the error message, it has been
>>>>>>>> handled
>>>>>>>> and that's why you are getting the DONE status back. We're looking
>>>>>>>> to
>>>>>>>> changing this default behavior for a next release of Camel.
>>>>>>>>
>>>>>>>> For now, you can configure a more appropriate ErrorHandler yourself.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> If
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> you want no error handling by Camel at all, you can use
>>>>>>>
>>>>>>>
>>>>>>>> errorHandler(noErrorHandler()) at the top of your RouteBuilder to
>>>>>>>> get
>>>>>>>> this
>>>>>>>> done. This page (
>>>>>>>> http://activemq.apache.org/camel/error-handler.html
>>>>>>>> )
>>>>>>>> shows you a bit more information about configuring Camel error
>>>>>>>> handler
>>>>>>>> strategies. You can also find examples on how to configure the
>>>>>>>> deadletterchannel. If you want the DeadLetterChannel handling to
>>>>>>>> fail
>>>>>>>> (instead of log) after the redelivery attempts, you can end the
>>>>>>>> deadLetterChannel() clause in your RouteBuilder with .throwFault()
>>>>>>>> to
>>>>>>>> force
>>>>>>>> the exception.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Gert
>>>>>>>>
>>>>>>>>
>>>>>>>> Manuel EVENO wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I've got a mediation with cxf-bc:consumer -> camel (
>>>>>>>>> cxf-bc:provider
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ->
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> saxon:xquery )
>>>>>>>
>>>>>>>
>>>>>>>> Here is the camel route :
>>>>>>>>> from("jbi:service:
>>>>>>>>> http://hello.samples.sofinco.com/HelloServiceRoute";)
>>>>>>>>> .to("jbi:endpoint:
>>>>>>>>> http://hello.samples.sofinco.com/HelloService/HelloService";)
>>>>>>>>> .to("jbi:endpoint:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>> http://hello.samples.sofinco.com/HelloServiceTransform/HelloServiceTransform
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ");
>>>>>>>
>>>>>>>
>>>>>>>> When the called service (the one used by cxf-bc:provider) is
>>>>>>>>> unreachable,
>>>>>>>>> no exception is returned to the calling client (the one calling the
>>>>>>>>> ESB).
>>>>>>>>> The client failed either on a timeout (if the redelivery process
>>>>>>>>> takes
>>>>>>>>> long time) or by receiving a wrong ouput message (the input
>>>>>>>>> message)
>>>>>>>>> Why doesn't the default behavior simply send an error ?
>>>>>>>>>
>>>>>>>>> More strange, the message exchange finished on a 'done' status
>>>>>>>>> instead
>>>>>>>>> of
>>>>>>>>> a 'error' status ...
>>>>>>>>>
>>>>>>>>> How to configure servicemix (or camel) to send an error back to the
>>>>>>>>> client
>>>>>>>>> when an error occurs in a message exchange
>>>>>>>>> and after the redelivery attempts all failed ?
>>>>>>>>>
>>>>>>>>> Manuel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> -----
>>>>>> ---
>>>>>> Gert Vanthienen
>>>>>> http://www.anova.be
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://www.nabble.com/Understanding-the-default-behavior-on-exception-tp18530599p18564323.html
>>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
