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
