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. 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. 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! 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. Apart from the above I found some minor issues: - handler method "cleanup" is never called - 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). - it would be great if modules could be disengaged using the admin frontend - 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. - 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? 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]
