On Dec 28, 2007 9:24 PM, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
> No no , we are not going to remove the phases from axis2.xml . We will
> keep then as it is , however we can add new phases without changing
> that.
Why we need to keep this if we have dynamic phase support?
I think before doing any implementation we need to come to an agreement with
what we expect as the dynamic phase support.
Let me express my point of view.
Currently axis2 users can only define phases in axis2.xml. The reason for
this is there is no way to define phases in the module.xml files. If we can
let users to define phases in module.xml files then there is no need to
define phase or flows in axis2.xml at all. axis2.xml can only be used to
define AxisConfiguration parameters.
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.
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>
In this way the only thing users have to learn about the phase and handlers
is that.
'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.
For now handlers can be defined in axis2.xml and module.xml and the rules
are different when defining in axis2.xml and moulde.xml. When defining in
axis2.xml handlers should define within phases and when defining at
module.xml that has to define directly under flow and set the phase using
order element.
if we take deepals' improvement still these complexity is there and further
we have one way of defining phase rules and another way of defining handler
rules.
Phase rule -> directly in phase element
<phase name="foo" after="a" before="b">
handler rule -> using order element
<handler name="foo">
<order after="a"/>
</handler>
And also in an module.xml handlers can either put directly under a flow or
under a phase.
So there are lot of rules to learn before start writing modules.
To be honest when I first lean about the axis2 phases it was difficult me to
understand this.
<phase name="Transport">
<handler name="RequestURIBasedDispatcher"
class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher">
<order phase="Transport"/>
</handler>
</phase>
Here within the transport phase we have a handler and within the handler we
have an element called order which has an attribute phase="Transport". What
does this means? Later I found that this <order phase="Transport"/> is
actually used in module.xml to place the handler in the correct phase since
phases can not be defined in module.xml. So we have to remove this order
element and phase attribute if we going to add dynamic phases.
With dynamic phases we must let users to define phase rules and handler
rules any declarative manner.
eg.
Lets say we have one module and it has these two phases like this.
<phase name="A" before="B" after="C"/>
<phase name="D" before="B" after="A"/>
then the resulting flow should be
C, A, D, B
we have to get the same thing if it written in the reverse way
<phase name="D" before="B" after="A"/>
<phase name="A" before="B" after="C"/>
One thing we have to understand is that, there may be many ways to arrange
the phase using the given rules. So in that case we have to come up with one
possible solution. if there is no possible solution as Glen has mentioned it
should gives an error.
Referring phases defined in other modules.
Lets take two modules with these phases.
module 1
<phase name="A" >
<handler name="h1" before="h2"/>
</phase>
moulde 2
<phase name="A" >
<handler name="h2"/>
</phase>
if we have both modules global chain would be something like this
<phase name="A" >
<handler name="h1" />
<handler name="h2"/>
</phase>
if only one module 1 exists
<phase name="A" >
<handler name="h1" />
</phase>
if only module 2 exists
<phase name="A" >
<handler name="h2"/>
</phase>
The basic idea is that we have to come up with a resulting handler chain
which satisfies the declarative rules defined by the user. Here as I
mentioned earlier we have to come up with a one possible solution. if there
is no solution should give an error and shutdown the server. Since if we
take module like security either we have to deploy it correctly or shutdown.
If we can agreed upon this I can start working on an algorithm to get the
resulting phase chain from the phase defined in the module.xml files.
Thanks,
Amila.
>
> -Deepal
>
> On 12/28/07, Amila Suriarachchi <[EMAIL PROTECTED]> wrote:
> > On Dec 27, 2007 9:38 PM, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
> >
> > > On 12/27/07, David Illsley <[EMAIL PROTECTED]> wrote:
> > > > Glen,
> > > > It's just as well I saw you volunteering and didn't do it as well,
> > > > 'cos I was tempted :-)
> > >
> > > :)
> > >
> > > So that is why I implement that :)
> > >
> > >
> > > >
> > > > +1 to your more advanced options in general terms.
> > > >
> > > > Do you have a defined behaviour when multiple modules define phases
> > > > with the same name, or with the same name as a statically defined
> > > > phase? Presumably the first/static declaration wins and you trace
> out
> > > > the multiple declaration failure?
> > >
> > > In my implementation if two modules try to add the same phase then th
> fist
> > > win.
> >
> >
> > I happened to look at the axis2.xml and saw still all the phases are
> there.
> > After this commit I think
> > axis2.xml must be cleaned up and only Transport and Dispatch phases must
> be
> > there.
> >
> >
> > What do you mean by wining and loosing at the above statement.
> > Lets take this scenario.
> > Addressing module define a phase called 'Addressing' and Sandesha module
> > wants to add a handler to the
> > this Addressing phase. Can this be archived? If so how are we going to
> > write the two module.xml s?
> >
> > Currently sandesha module.xml has this phase rule.
> >
> > <handler name="SequenceIDDispatcher"
> > class="org.apache.sandesha2.handlers.SequenceIDDispatcher">
> > <order phase="Addressing" before="AddressingBasedDispatcher" />
> > </handler>
> >
> >
> >
> > thanks,
> > Amila.
> >
> >
> > >
> > > -Deepal
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
> >
>
>
> --
>
>
>
>
>
> ============================
> Deepal Jayasinghe
> Lanka Software Foundation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Amila Suriarachchi,
WSO2 Inc.
