Excellent. Looks good, though I think you've got an extra variable - activePhaseConstraints in DeployableChain which doesn't appear to be used? David
On Jan 2, 2008 3:17 PM, Glen Daniels <[EMAIL PROTECTED]> wrote: > Happy New Year to you too! > > http://svn.apache.org/viewvc?rev=607662&view=rev > > The code's checked in as > org.apache.axis2.engine.Deployable/DeploymentChain. Right now this is > only for processing <phase> elements in module.xml, but I'd like to > expand it so that we can use the same code to deploy Phases and Handlers > within Phases. > > --Glen > > > David Illsley wrote: > > Hi Glen, > > Happy New Year :-) > > I was wondering when we might get a chance to see your dynamic phase code? > > Cheers, > > David > > > > On Dec 31, 2007 6:08 AM, 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] > >> > >> > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
