Hi,
What's the ServiceMix version you are using.
I believe the exception catch problem from cxf bc provider already get
fixed by SM-1372, [1] track this issue, you need use smx 3.2.2 snapshot.
[1]https://issues.apache.org/activemq/browse/SM-1372
Freeman
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.
