In my personal opinion I see the invokeFault(..) [or whatever it will be called] as an elegant way of handling the error.So I don't think it's complicating things. it's actually a better way of dealing with the complication :)
The very reason why we need a fault flow is to avoid such fall through code in the handlers :)
On 8/17/05, Eran Chinthaka <
[EMAIL PROTECTED]> wrote:
Ok, can I know the things you are thinking of doing in the IN fault
flow, which you don't wanna do in the normal in flow (of course
something other than logging :) )
> Hi dims;
>
> Lets say that we have the fault information in the soap header (addressing)
> . In the current implementation what it does is when a message is received ,
> takes the inflow (inflow handles ) and give it to the engine and call
> engine.receive(msgContx) ,
> addressing handler is in that chain , so we do need to go throgh the inflow
> upto addressing handler to read the addressing headers to know the fault ,
> and then we can call engine.receiveFault();
>
> so we have to start the in-fault-flow invocation in the middle of in-flow;
> is that ok?
Isn't this complicating the things ???
Without doing the way you propose, you can achieve the samething like this.
1. Handler which handlers everything
invoke (msgctx){
if( env.getBody().hasFault()){
// do your fault stuff
}else{
// do normal stuff
}
}
2. Fault Handler (any use cases ??)
invoke (msgctx){
if(env.getBody().hasFault()){
// do your fault stuff
}
}
3. No Difference on faults handler
invoke (msgctx){
// act on msgctx. No difference
}
See my point ??
-- Chinthaka
--
Ajith Ranabahu
