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

Reply via email to