Hi Thilo; Excellent and very valuable comments !!!
I tried to answer few of them pls see my comments below; Thilo Frotscher wrote: > > Hello Axis2 team! > > I am trying to completely understand Axis2 phases, but while the concept > seems simple at first glance, I find it actually quite confusing the way > it is currently implemented. > > There are two types of phases: > - global/system/pre-defined phases > - operation-specific phases > > My understanding of the whole concept is that phases are used to define > *where* or *at which position* in the chain a particular handler will be > placed. Using the engagement mechanism you can define *if* or in which > cases a module/handler will be invoked (for all services, a service > group, > a service or an operation). > > The confusion starts if a handler is placed into one of the global > phases, > let's say into PreDispatch. According to the theory above, we now know > *where* in the chain the handler would be invoked. We also know, that the > handler would *generally* be available to all services, because it > was not placed into an operation-specific phase. > agreed. > Now, let's say you don't want to engage the module/handler globally. > Instead, you engage it with one particular service or even with one > particular operation. This can be done either by configuration file or > using the admin frontend. My expectation is then, that the handler > will be > invoked *only* if a message is addressed to the service or operation I > engaged the module/handler with. This expectation is even confirmed when > I click on "Available Services" in the admin frontend, where services, > operations and their engaged modules are displayed. The engagement is > displayed *only* for the service or operation I picked. > agreed. > However, when sending messages to this service, Axis2 1.0 will behave > differently. A handler that belongs to a global phase will be invoked for > *all* services and *all* operations after it was engaged with a *single* > service or *single* operation only. This is very confusing! > agreed , but that is the behavior :-) . The problem is until you find the service and operation (until dispatch happen) you dont know the operation specific chains. So when you engage a module to a service , then if add a handler to global phases as you said it will run irrespective of the service. Since anyone can add handler to global phases and no one keep track of that , at the run time Axis2 can not figure out who add this handler into here. I know its a serious problem but , it is very difficult to answer. The only solution is handler should intelligent enough to decide whether to run or not. btw do you have any idea of solving this issue ? > The problem is obvious with Rampart, however it works around this. It > places > its handlers into global phases, so that they are always invoked, whether > security is needed or not. Whether it has any effect or not depends on > the > configuration of a service or operation. Only if these configurations > contain > any parameters for Rampart, then Rampart will do something. Otherwise > it will > not. Hmmm... wouldn't the whole thing be easier to understand if > Rampart could > be switched on/off for the single services or operations by engagement? > > Perhaps I just misunderstand the concept. If that's the case please > give some > advice. But if I am right, then please review this part of the phase > concept. > IMHO it is very confusing that engaging a handler with *one* operation > can mean > that the handler will be invoked for *all* services and *all* operations. ya that is happening. > > > > Apart from the above I found some minor issues: > > - handler method "cleanup" is never called one more JIRA > > - if a handler throws an exception in the In-Flow, the flow is cancelled > immediately. AxisEngine carries on with an operation-specific > OutFaultFlow > (if there already is an operation context) and then with the global > out fault flow. I think instead of just cancelling the in-flow, there > should be a mechanism that informs prior handlers of the in-flow > about the > occurrence of the exception, so that they have a chance to undo their > functionality. Axis 1.x had something like this (onFault method). I also think we need to take this into consideration , so +1 for the idea. we need to call handler.onFault(); for all the prior handlers. > > - it would be great if modules could be disengaged using the admin > frontend > pls create a JIRA so that we wont forget that. > - on the client side, OutInAxisOperationClient (method "send") does *not* > invoke receiveFault on the AxisEngine (and thereby InFaultFlow) if a > service responses with a SOAP fault. Instead, it aways invokes receive > (i.e. InFlow). I believe that this is a bug. I just fixed in the current SVN > > - Why is there a "Security" phase in th In Flow, but not in the Out Flow? > Rampart puts its SecurityOutHandler into the "MessageOut" phase... > Wouldn't it be easier to understand if there was a Security phase in > the > Out Flow as well? Ruchith what do you think ? I am +1 of doing this change. > > > Thank you very much for any help and advice. > > Kind Regards, > Thilo > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Thanks, Deepal ................................................................ ~Future is Open~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
