On Aug 5, 2013, at 10:45 PM, Willem jiang <[email protected]> wrote:
> Hi Team,
>
> I just fixed CAMEL-6609[1] by calling the
> getConduitSelector().complete(cxfExchange) inside of my custom CallBack
> method. But I think I should fix it from CXF.
>
> I tried to add this call into the
> org.apache.cxf.message.Message.ClientCallback class, but I found I have to
> get the reference of ClientImpl to do that call.
> I also tried to add some code in the ClientImpl, but I found the
> ClientOutFaultObserver will call the ClientCallback handleException when
> exception is through, and I don't like the idea to let the
> ClientOutFaultObserver hold the reference of ClientImpl.
>
> Is there any good way to let the getConduitSelector().complete(cxfExchange)
> be called rightly, when the exception is thrown from the interceptor chain.
Shouldn't this just be adding a couple more calls to ….complete(exchange) in
the ClientImpl.processResult, particularly in the if (callback != null) paths?
For the outFault case… in ClientImpl where it adds it to the chain, do:
chain.setFaultObserver(new MessageObserver() {
public void onMessage(Message message) {
outFaultObserver.onMessage(message);
getConduitSelector().complete(message.getExchange());
}
});
to wrapper it and handle the completions. That avoids adding the ClientImpl
directly to the ClientOutFaultObserver.
Actually, in ClientImpl.prepareConduitSelector(…), the conduit selector is set
into the exchange. Thus, at any point, you should be able to do
message.getExchange().get(ConduitSelector.class)…. and use it.
Dan
>
> [1]https://issues.apache.org/jira/browse/CAMEL-6609
>
> Regards,
>
> Willem
>
>
>
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
