After looking at the current code, I'd like to rework Phases a bit.
I think the whole "pre-dispatch / post-dispatch / checker" architecture
is very confusing (and potentially error-prone) as it stands. Rather
than having an explicit "post-dispatch" phase in order to do the checks
necessary after dispatching, I'd like to implement my original idea for
Phases, which is that each Phase *itself* has pre and post conditions.
Since this really means that there is some work that might need to be
done at the beginning/end of a Phase (more than just checking
conditions), I'm calling the new methods startPhase/endPhase:
class Phase {
// Default impls do nothing. Overrides will check
// conditions and potentially throw Exceptions
public void startPhase(MessageContext ctx)
throws AxisFault {
}
public void endPhase(MessageContext ctx)
throws AxisFault {
}
public final void invoke(MessageContext ctx) {
startPhase();
... run through included handlers ...
endPhase();
}
}
Then rather than doing all the configuration to get the post-dispatch
stuff ordered correctly, we'd define:
class DispatchPhase extends Phase {
public void endPhase(MessageContext ctx) throws AxisFault {
...
if (dispatchNotComplete) {
throw new AxisFault("Dispatching not complete!");
}
// Dispatch OK, locate contexts...
...
}
}
When defining phases in axis2.xml, we'd add a class attribute:
<phase name="Dispatch" class="org.apache.axis2.phases.DispatchPhase"/>
I think this ends up being much cleaner, and it's also clearer what's
going on when a user wants to add a custom Phase with pre- and
post-conditions - this way the semantics of what makes the Phase special
live in the Phase implementation class, not in lots of different pieces
which all must be deployed in a certain way to work correctly.
Once this is done we can do away with the "PostDispatch" Phase, a
further simplification.
I'd like to make this change soon after ServiceGroup work is checked in.
Thoughts?
--Glen
