Re: [Axis2] Dynamic Phase support

[Amila Suriarachchi <am...@gmail.com>]

here is the algorithm,
https://issues.apache.org/jira/browse/AXIS2-3421

this uses a similar technique as mathematical induction. This can validate
any phase rules given
and gives a possible phase list only if there is a solution.

Thanks,
Amila.

On Dec 31, 2007 2:38 PM, Amila Suriarachchi <am...@gmail.com>
wrote:

> 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
> axis2.xml?
>
> 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
> module.xml.
>
> 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.
>
> Thanks,
> Amila.
>
> On 12/31/07, Glen Daniels <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>



-- 
Amila Suriarachchi,
WSO2 Inc.