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.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
