axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <chintha...@gmail.com>
Subject Re: [Axis2] How to Handle faults
Date Wed, 17 Aug 2005 11:31:04 GMT
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
Mime
View raw message