Hi all:
A huge +1 to allowing Modules (and maybe Services) to deploy their own
Phases. We can perhaps discuss this on this week's chat, but a quick
summary from my POV...
* An ExecutionChain is just a list of named Handlers which execute
in order.
* A Phase is (should be) just a Handler that happens to a) live
at the top level (i.e. not inside another Phase), and b) act as
a container for other Handlers. (also, it has pre and post
conditions, but that's not relevant here)
* When you deploy a Phase you're doing almost exactly the same
thing you do when you deploy a Handler within a Phase - you're
saying "add this named component to the EC, and please follow
these placement rules (BEFORE X, AFTER Y, etc)". As an
example, imagine this ExecutionChain:
1. Handler1
2. [PhaseA : Handler2, Handler5 ]
3. [PhaseB : Handler3]
4. Handler4
Now I deploy a Module which has "PhaseC AFTER PhaseA" and
"Handler6 IN PhaseC BEFORE Handler99"...
1. Handler1
2. [PhaseA : Handler2, Handler5 ]
3. [PhaseC : Handler99 ]
4. [PhaseB : Handler3 ]
5. Handler4
Doesn't that seem handy?
* If multiple Modules define the same Phase, it's no problem
as long as each deployment rule is checked out as the Module
is engaged. For instance, if another Module engaged after
the one above had declared "PhaseC BEFORE PhaseB" and another
Handler in PhaseC, we'd be fine. Doing this checking might
not be entirely necessary - as a first cut we could simply
let the first one to define a Phase (either core Axis2 or
a Module) deploy it, and then if we notice a duplicate name
later, just ignore it and assume it's ok.
* Doing this is, I think, an important part of the composability
puzzle - just like Module authors are allowed to define their
own Handlers, they should be able to declare the Phases in
which those Handlers do their work, without forcing the Axis2
admin to figure out how to deploy the correct Phases before
they can even use the Module.
--Glen
