Hi Tom,
Well instead of implementing custom exception logic inside the
PhaseInterceptor chain, I think you should supply a Fault
MessageObserver to listen for the exception and then deal with it. I
also don't think it should throw an exception that the ClientImpl
catches. The Client can do message.getContent(Exception.class) or it can
do message.getExchange().getFaultMessage().getContent(Exception.class)
to look for an exception.
Can we rework things this way?
- Dan
Li, Tao (Tom) wrote:
Hi Dan.D,
This modification is to handling the exception throwing at the executing the
chain for Client to send out the request.
Before my modification, when the exception occurred, the faultObserver is null
at client for out chain. So the chain is just aborted. But the out chain is
nested calling in execution, in the case that the exception occurred after
MessageSenderInterceptor makes the sending wrong message to server.
I think, for the client-out Exception thrown during chain execution, the
exception can be throw back direct to client proxy invoke, since it's not
thrown out by server.
e.g.
When JAXB Marshal Exception occurred during BareOutInterceptor, chain state
changed to aborted. As the BareOutInterceptor is in sub-chain (previous chain
call message.getInterceptorChain.doIntercept()) of SoapOutInterceptor, and
SoapOutInterceptor is in sub-chain of StaxOutInterceptor, and
StaxOutInterceptor is in sub-chain of MessageSenderInterceptor, it will return
one by one to the outer interceptor, and the chain is not really stopped,
finally it will flush to the server.
If we don't throw the exception from Chain, we need to add a faultObserver to
the chain in ClientImpl's invoke method, but what this faultObserver needs to
do is throw the Exception to the invoke method which called chain.doIntercept,
that makes this faultOberser looks redundant.
Thanks.
Tom
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 6:15 AM
To: [email protected]
Cc: [email protected]
Subject: Re: svn commit: r467624 - in /incubator/cxf/trunk:
api/src/main/java/org/apache/cxf/phase/
rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/int
erceptor/
rt/bindings/soap/src/test/java/org/apache/cxf/binding/soap/att
achments/
rt/core/ rt/core/src
Hi Tom,
Can you explain why we're doing this here? I'm not sure that
the chain
should depend on knowledge about whether a client is running
it or not.
Also, if an Exception happens I think it is the client's
responsibility
to check for a message.getContent(Exception.class) - I
thought we were
already doing so even! Can you please look at changing this
back so we
aren't rethrowing anything?
Thanks,
- Dan
[EMAIL PROTECTED] wrote:
Modified:
incubator/cxf/trunk/api/src/main/java/org/apache/cxf/phase/Pha
seInterceptorChain.java
URL:
http://svn.apache.org/viewvc/incubator/cxf/trunk/api/src/main/java/org/apache/cxf/phase/PhaseInterceptorChain.java?view=diff&rev=467624&r1=467623&r2=467624
==============================================================================
---
incubator/cxf/trunk/api/src/main/java/org/apache/cxf/phase/PhaseInterceptorChain.java
(original)
+++
incubator/cxf/trunk/api/src/main/java/org/apache/cxf/phase/PhaseInterceptorChain.java
Wed Oct 25 05:36:43 2006
@@ -154,6 +154,13 @@
if (faultObserver != null) {
faultObserver.onMessage(message);
+ } else {
+ // Client out-bound message, directly throw exception back
to client
+ if (message.getExchange() != null
+ && message == message.getExchange().getOutMessage()
+ && message.containsKey(Message.REQUESTOR_ROLE)) {
+ throw new RuntimeException(ex);
+ }
}
state = State.ABORTED;
}
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog