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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Amila Suriarachchi, > WSO2 Inc. > -- Amila Suriarachchi, WSO2 Inc.
