Hi Ajith and all, > One can ask at this point whether it would be possible to handle this by > putting a handler that looks at the SOAP body and determines whether it's a > fault or not. Well, not in all cases. The message can be encrypted hence the > security handler should run first if the body needs to be inspected. > Again there's the vague area of where the fault-in-flow should lead to. > Obviously it should end at the Message receiver. However the message receiver > should somehow be informed that this is a fault, perhaps through a different > method in the message receiver interface (Currently the message receiver > interface has only one method, receive(…). Perhaps we can put a > receiveFault(…) method for the fault-in-flow to call)
Why does the message receiver be notified *explicitly* about a fault, with this much of pain. MR can simply do a small check on the msgctx and switch, if required. (msgctx.getSOAPEnvelope().getBody().hasFault() ). > > Solutions > > These are the possible solutions > > Have a switching handler in the middle of the inflow. This handler > (referred to as the switching handler afterwards) has to run after some > of the essential handlers. In more technical words, it should be > resolvable to a fault or not at the switching handler. The fault flow > ends at the message receiver that may invoke a separate method in > the MR or just inject the message context which has a flag saying it's a > fault. > > Drop the concept of fault-in-flow completely. Necessary handlers can > implement fall through mechanisms to handle an incoming fault. +1. I don't think we have a necessity to incorporate the fault handling mechanism to the main control flow. You have a good and acceptable way to do the samething. And if we do option #1 you are unnecessarily complicating the common case. Anyway, I don't think there are that much of use cases that have services which *expects* faults as IN messages. What I suggest is don't have this in the main control flow. Let the user put the required logic in handlers and in MR. Regards, Chinthaka
