When I think faults I always think soap faults. And I think that was the main use case behind adding the the fault message in the exchange. But the fact is that a fault is just the out message from soap. A soap processor could inspect that out message and notice it's of a fault variety. So my vote is to eliminate the fault message and store faults in the out message.
IMO, exceptions thrown by camel processors should be due to internal camel errors due to things like not having connectivity or invalid configuration etc. etc. Accessing a soap service which returns a fault message should not be an exception, it's just a error response that needs to get routed. Regards, Hiram On Thu, Apr 17, 2008 at 12:47 AM, Hadrian Zbarcea <[EMAIL PROTECTED]> wrote: > Hi, > > We had an issue in camel (see end of nabble thread here: > http://www.nabble.com/in-out-fault-messages-discussion-td14170013i20.html) > and we'd highly appreciate your input on this. > > In brief, there is a proposal to get rid of faults. Most of the protocols > do not distinguish between faults and exceptions, but jbi, jsr181, wsdl to. > Should we remove faults from the model? And if we do so should faults be > more like outputs or more like errors? > > Thanks > Hadrian > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
