axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <>
Subject Re: [Axis2] Dynamic Phase support
Date Mon, 31 Dec 2007 09:08:46 GMT
hi all,

First of all I don't see any problem of packaging default phases in a
separate module. What is the advantage we get by putting them in

if we keep the existing phases in the axis2.xml then we can not stop
the fact that people want to change the axis2.xml time to time. This
is the main idea of going for dynamic phases. For an example now
Security phase is before dispatch phase. if security people wants to
move it after dispatch phase still they wants to change the axis2.xml.
the only way to get rid of this problem is to define phases only in

On the other hand if we define some phases in axis2.xml and others in
module.xml then it may confuse people. for an example now there are
three security phases in axis2.xml and we are going to say add the
last one to security module.xml.

Therefore I think better to have either dynamic phases or static
phases rather than both. Anyway I am ok with this approach as well .

I have written an algorithum (a model sample to demostrate the
algorithum) for process phases for full dynamic case. I'll attach it
as jira in any case we decied to go for it.


On 12/31/07, Glen Daniels <> wrote:
> Hi Deepal, Amila:
> Deepal Jayasinghe wrote:
> > The problem is we have a set of default handlers then we add using
> > axis2.xml , so example for those handler could be our dispatchers. So
> > if we remove those from axis2.xml where are we going  to put them ?
> The core stuff like basic dispatchers should, I think, stay in
> axis2.xml.  But module-specific stuff (including the WSA dispatcher)
> could move out to the module.xmls.
> >> I think before doing any implementation we need to come to an agreement
> with
> >> what we expect as the dynamic phase support.
> > +1
> OK.  I made some more implementation progress, which we should discuss.
> >> Then the question comes, where we going to put the dispatch and transport
> >> phases? Those things can also be added to new module called Dispatch
> module
> >> (or default phase module) and shift with axis2 like addressing module.
> >
> > :)
> >
> > I think those dispatchers are core part of axis2 so , I do not agree
> > on moving them to a module. Rather I really wanted to get rid from
> > addressing module and keep them as core part of Axis2.
> Hm - I agree with the first sentence, I think there are and should be
> core dispatchers in axis2.  I'm not sure about the second sentence...
> >> So a module.xml (the only place to define the phases and hence handlers)
> has
> >> the following format.
> >>
> >> <module name="foo">
> >>    <Inflow>
> >>       <phase name="A" before="B" after="C">
> >>                 <handler name="a" before="b" after="c"/>
> >>                 <!-- other handlers under this phase -->
> >>       </phase>
> >>        <!-- other phase for this flow -->
> >>   </Inflow>
> >>   <!-- other flows -->
> >> </module>
> I like this syntax a lot - this way it could be identical between
> axis2.xml and module.xml.  That seems like a very good thing to me.  We
> need to keep supporting the old syntax too, but this seems much cleaner.
> Note that the desired behavior here is a merge - so if multiple modules
> (or core stuff in axis2.xml) all put handlers into the "Foo" phase, we
> should verify that all the constraints (including the location of "Foo"
> in the flow) are compatible with each other, and calculate the
> end-result for the order based on all of them.
> >> 'Phases and Handlers can only be defined in the module.xml and a phase
> can
> >> be placed within a flow using phase rules (after, before, phase first,
> phase
> >> last) and a handler can be placed within a phase using handler rules.
> Aside from the "only", this looks great. :)  The code that I recently
> implemented supports this idea in general - not specifically tied to
> Handlers or Phases, but usable for either/both.
> Cheers,
> --Glen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Amila Suriarachchi,
WSO2 Inc.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message