You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Chamikara Jayalath <ch...@gmail.com> on 2006/04/03 09:39:17 UTC
[Axis2] Giving modules the ability to define their own phases
Hi All,
Phases are a nice feature in axis2 that is used by many module authors. But
there is a small defect in this that limits its usability to some extend.
This is the inability for modules to add their own phases without doing
changes to the axis2.xml.
For e.g. Sandesha2 module expect to add its handlers to a custom phase
called 'RMPhase'. But since this cannot be added by itselt (for e.g. by
mentioning in the module.xml), users have to always edit the axis2.xml file
by hand and add this phase. This makes the task difficult for users and is
error prone.
I believe it will be useful to make this feature available. My be we can
have a switch in axis2.xml which tells weather modules are allowed to
dynamically add their own phases or not.
comments ... ?
Chamikara
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Chinthaka,
See my comments below,
On 4/3/06, Eran Chinthaka <ch...@opensource.lk> wrote:
>
>
>
> My suggestion is Axis2 admin sets a flag in axis2.xml, allowing module
> authors to add their own phases, during module init.
>
> If the flag is set, then Sandesha can add a phase.
+1
BTW, why do you wanna have your own phase ?
This is to easily seperate the handlers of a certain module. For e.g. a
WS-Eventing implementation which need RM support may want to add its
handlers after a RMPhase.
Also some modules may need to add their handlers after a SecurityPhase.
Chamikara
-- Chinthaka
>
>
>
> Deepal Jayasinghe wrote:
> > Hi Chamikara
> >
> > I remember we had this discussion at the last f2f we had in Colombo and
> > the final conclusion was not to allows module to add phases by itself.
> > If some module require some specific phase then adding a phase is just
> > a matter of changing the axis2.xml.
> >
> > I know if some one want to change axis2.xml in oder to deploy a module
> > that is not a good idea and that break modulelarity of a module. There
> > for my suggestion is we should treat module like Security , Sandesha
> > separately and if they want some phase we should add them into
> > default_axis2.xml
> >
> > I am +1 on supporting Sandesha , Security etc by default .
> >
> > And I dont like the idea of adding phases by module when they get
> > initialize , that may lead system into unknown state , since no one know
> > what we are going to have at the runtime.
> >
> >
> > Chamikara Jayalath wrote:
> >
> >> Hi All,
> >>
> >> Phases are a nice feature in axis2 that is used by many module
> >> authors. But there is a small defect in this that limits its usability
> >> to some extend. This is the inability for modules to add their own
> >> phases without doing changes to the axis2.xml.
> >>
> >> For e.g. Sandesha2 module expect to add its handlers to a custom phase
> >> called 'RMPhase'. But since this cannot be added by itselt (for e.g.
> >> by mentioning in the module.xml), users have to always edit the
> >> axis2.xml file by hand and add this phase. This makes the task
> >> difficult for users and is error prone.
> >>
> >> I believe it will be useful to make this feature available. My be we
> >> can have a switch in axis2.xml which tells weather modules are allowed
> >> to dynamically add their own phases or not.
> >>
> >> comments ... ?
> >>
> >>
> >> Chamikara
> >
> >
>
>
>
>
>
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Deepal,
I think you have misinterpretted my statement, a module adding a new phase.
What I mean here is a module mentioning the new module name in the
module.xml and the axis2 deployment mechanism adding that phase to the
system.
So the module does not hv to do anything like adding phases in to operation
chains. These should be done by the deployment mechanism.( even there Isnt
it basically adding this phase to the operations or services that have this
module engaged ?)
Chamikara
On 4/3/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> hi;
>
> If module is trying a add a phase into global chain then there wont be a
> big problem , but if that is going to add a phase into operation chain ,
> then the module has to get each operations and add the phase into their
> chains. Module has to do that as a result of operations get its own
> phase chain at the deployment time.
>
> So lets improve the generic phase scenario I mentioned sometimes ago
> appropriately , so that there wont be any problem.
>
>
>
> Eran Chinthaka wrote:
>
> >My suggestion is Axis2 admin sets a flag in axis2.xml, allowing module
> >authors to add their own phases, during module init.
> >
> >If the flag is set, then Sandesha can add a phase.
> >
> >BTW, why do you wanna have your own phase ?
> >
> >-- Chinthaka
> >
> >
> >
> >Deepal Jayasinghe wrote:
> >
> >
> >>Hi Chamikara
> >>
> >>I remember we had this discussion at the last f2f we had in Colombo and
> >>the final conclusion was not to allows module to add phases by itself.
> >>If some module require some specific phase then adding a phase is just
> >>a matter of changing the axis2.xml.
> >>
> >>I know if some one want to change axis2.xml in oder to deploy a module
> >>that is not a good idea and that break modulelarity of a module. There
> >>for my suggestion is we should treat module like Security , Sandesha
> >>separately and if they want some phase we should add them into
> >>default_axis2.xml
> >>
> >>I am +1 on supporting Sandesha , Security etc by default .
> >>
> >>And I dont like the idea of adding phases by module when they get
> >>initialize , that may lead system into unknown state , since no one know
> >>what we are going to have at the runtime.
> >>
> >>
> >>Chamikara Jayalath wrote:
> >>
> >>
> >>
> >>>Hi All,
> >>>
> >>>Phases are a nice feature in axis2 that is used by many module
> >>>authors. But there is a small defect in this that limits its usability
> >>>to some extend. This is the inability for modules to add their own
> >>>phases without doing changes to the axis2.xml.
> >>>
> >>>For e.g. Sandesha2 module expect to add its handlers to a custom phase
> >>>called 'RMPhase'. But since this cannot be added by itselt (for e.g.
> >>>by mentioning in the module.xml), users have to always edit the
> >>>axis2.xml file by hand and add this phase. This makes the task
> >>>difficult for users and is error prone.
> >>>
> >>>I believe it will be useful to make this feature available. My be we
> >>>can have a switch in axis2.xml which tells weather modules are allowed
> >>>to dynamically add their own phases or not.
> >>>
> >>>comments ... ?
> >>>
> >>>
> >>>Chamikara
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-04-05 at 09:08 -0400, Glen Daniels wrote:
> Hi Deepal:
>
> > Now I also feel this is a cool feature , but is this a 1.0 requirement
> > ? ................ :)
>
> It's an architectural thing about the way Handlers and Phases are dealt
> with. Therefore I think it's kind of a major change, not necessarily
> code-wise, but conceptually. That being the case, I'd *rather* see it
> in 1.0 if possible, but I certainly think it's something that can be
> changed post-1.0 (hopefully soon after) as well. Especially if we're
> really doing the "release early release often" thing, I'd be OK with
> that too.
We're not going to be done with architectural improvements after 1.0 for
sure! So let's put this after .. this is not going to change but add, so
I see no problem with looking at this beyond 1.0.
I *definitely* want to do release early/often .. once a quarter would be
ideal IMO.
Sanjiva.
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal:
> Now I also feel this is a cool feature , but is this a 1.0 requirement
> ? ................ :)
It's an architectural thing about the way Handlers and Phases are dealt
with. Therefore I think it's kind of a major change, not necessarily
code-wise, but conceptually. That being the case, I'd *rather* see it
in 1.0 if possible, but I certainly think it's something that can be
changed post-1.0 (hopefully soon after) as well. Especially if we're
really doing the "release early release often" thing, I'd be OK with
that too.
--Glen
>> Hi all:
>>
>> A huge +1 to allowing Modules (and maybe Services) to deploy their own
>> Phases. We can perhaps discuss this on this week's chat, but a quick
>> summary from my POV...
>> [...]
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi glen;
Now I also feel this is a cool feature , but is this a 1.0 requirement
? ................ :)
Glen Daniels wrote:
> Hi all:
>
> A huge +1 to allowing Modules (and maybe Services) to deploy their own
> Phases. We can perhaps discuss this on this week's chat, but a quick
> summary from my POV...
>
> * An ExecutionChain is just a list of named Handlers which execute
> in order.
>
> * A Phase is (should be) just a Handler that happens to a) live
> at the top level (i.e. not inside another Phase), and b) act as
> a container for other Handlers. (also, it has pre and post
> conditions, but that's not relevant here)
>
> * When you deploy a Phase you're doing almost exactly the same
> thing you do when you deploy a Handler within a Phase - you're
> saying "add this named component to the EC, and please follow
> these placement rules (BEFORE X, AFTER Y, etc)". As an
> example, imagine this ExecutionChain:
>
> 1. Handler1
> 2. [PhaseA : Handler2, Handler5 ]
> 3. [PhaseB : Handler3]
> 4. Handler4
>
> Now I deploy a Module which has "PhaseC AFTER PhaseA" and
> "Handler6 IN PhaseC BEFORE Handler99"...
>
> 1. Handler1
> 2. [PhaseA : Handler2, Handler5 ]
> 3. [PhaseC : Handler99 ]
> 4. [PhaseB : Handler3 ]
> 5. Handler4
>
> Doesn't that seem handy?
>
> * If multiple Modules define the same Phase, it's no problem
> as long as each deployment rule is checked out as the Module
> is engaged. For instance, if another Module engaged after
> the one above had declared "PhaseC BEFORE PhaseB" and another
> Handler in PhaseC, we'd be fine. Doing this checking might
> not be entirely necessary - as a first cut we could simply
> let the first one to define a Phase (either core Axis2 or
> a Module) deploy it, and then if we notice a duplicate name
> later, just ignore it and assume it's ok.
>
> * Doing this is, I think, an important part of the composability
> puzzle - just like Module authors are allowed to define their
> own Handlers, they should be able to declare the Phases in
> which those Handlers do their work, without forcing the Axis2
> admin to figure out how to deploy the correct Phases before
> they can even use the Module.
>
> --Glen
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi all:
A huge +1 to allowing Modules (and maybe Services) to deploy their own
Phases. We can perhaps discuss this on this week's chat, but a quick
summary from my POV...
* An ExecutionChain is just a list of named Handlers which execute
in order.
* A Phase is (should be) just a Handler that happens to a) live
at the top level (i.e. not inside another Phase), and b) act as
a container for other Handlers. (also, it has pre and post
conditions, but that's not relevant here)
* When you deploy a Phase you're doing almost exactly the same
thing you do when you deploy a Handler within a Phase - you're
saying "add this named component to the EC, and please follow
these placement rules (BEFORE X, AFTER Y, etc)". As an
example, imagine this ExecutionChain:
1. Handler1
2. [PhaseA : Handler2, Handler5 ]
3. [PhaseB : Handler3]
4. Handler4
Now I deploy a Module which has "PhaseC AFTER PhaseA" and
"Handler6 IN PhaseC BEFORE Handler99"...
1. Handler1
2. [PhaseA : Handler2, Handler5 ]
3. [PhaseC : Handler99 ]
4. [PhaseB : Handler3 ]
5. Handler4
Doesn't that seem handy?
* If multiple Modules define the same Phase, it's no problem
as long as each deployment rule is checked out as the Module
is engaged. For instance, if another Module engaged after
the one above had declared "PhaseC BEFORE PhaseB" and another
Handler in PhaseC, we'd be fine. Doing this checking might
not be entirely necessary - as a first cut we could simply
let the first one to define a Phase (either core Axis2 or
a Module) deploy it, and then if we notice a duplicate name
later, just ignore it and assume it's ok.
* Doing this is, I think, an important part of the composability
puzzle - just like Module authors are allowed to define their
own Handlers, they should be able to declare the Phases in
which those Handlers do their work, without forcing the Axis2
admin to figure out how to deploy the correct Phases before
they can even use the Module.
--Glen
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Deepal Jayasinghe <de...@opensource.lk>.
hi;
If module is trying a add a phase into global chain then there wont be a
big problem , but if that is going to add a phase into operation chain ,
then the module has to get each operations and add the phase into their
chains. Module has to do that as a result of operations get its own
phase chain at the deployment time.
So lets improve the generic phase scenario I mentioned sometimes ago
appropriately , so that there wont be any problem.
Eran Chinthaka wrote:
>My suggestion is Axis2 admin sets a flag in axis2.xml, allowing module
>authors to add their own phases, during module init.
>
>If the flag is set, then Sandesha can add a phase.
>
>BTW, why do you wanna have your own phase ?
>
>-- Chinthaka
>
>
>
>Deepal Jayasinghe wrote:
>
>
>>Hi Chamikara
>>
>>I remember we had this discussion at the last f2f we had in Colombo and
>>the final conclusion was not to allows module to add phases by itself.
>>If some module require some specific phase then adding a phase is just
>>a matter of changing the axis2.xml.
>>
>>I know if some one want to change axis2.xml in oder to deploy a module
>>that is not a good idea and that break modulelarity of a module. There
>>for my suggestion is we should treat module like Security , Sandesha
>>separately and if they want some phase we should add them into
>>default_axis2.xml
>>
>>I am +1 on supporting Sandesha , Security etc by default .
>>
>>And I dont like the idea of adding phases by module when they get
>>initialize , that may lead system into unknown state , since no one know
>>what we are going to have at the runtime.
>>
>>
>>Chamikara Jayalath wrote:
>>
>>
>>
>>>Hi All,
>>>
>>>Phases are a nice feature in axis2 that is used by many module
>>>authors. But there is a small defect in this that limits its usability
>>>to some extend. This is the inability for modules to add their own
>>>phases without doing changes to the axis2.xml.
>>>
>>>For e.g. Sandesha2 module expect to add its handlers to a custom phase
>>>called 'RMPhase'. But since this cannot be added by itselt (for e.g.
>>>by mentioning in the module.xml), users have to always edit the
>>>axis2.xml file by hand and add this phase. This makes the task
>>>difficult for users and is error prone.
>>>
>>>I believe it will be useful to make this feature available. My be we
>>>can have a switch in axis2.xml which tells weather modules are allowed
>>>to dynamically add their own phases or not.
>>>
>>>comments ... ?
>>>
>>>
>>>Chamikara
>>>
>>>
>>
>>
>
>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Eran Chinthaka <ch...@opensource.lk>.
My suggestion is Axis2 admin sets a flag in axis2.xml, allowing module
authors to add their own phases, during module init.
If the flag is set, then Sandesha can add a phase.
BTW, why do you wanna have your own phase ?
-- Chinthaka
Deepal Jayasinghe wrote:
> Hi Chamikara
>
> I remember we had this discussion at the last f2f we had in Colombo and
> the final conclusion was not to allows module to add phases by itself.
> If some module require some specific phase then adding a phase is just
> a matter of changing the axis2.xml.
>
> I know if some one want to change axis2.xml in oder to deploy a module
> that is not a good idea and that break modulelarity of a module. There
> for my suggestion is we should treat module like Security , Sandesha
> separately and if they want some phase we should add them into
> default_axis2.xml
>
> I am +1 on supporting Sandesha , Security etc by default .
>
> And I dont like the idea of adding phases by module when they get
> initialize , that may lead system into unknown state , since no one know
> what we are going to have at the runtime.
>
>
> Chamikara Jayalath wrote:
>
>> Hi All,
>>
>> Phases are a nice feature in axis2 that is used by many module
>> authors. But there is a small defect in this that limits its usability
>> to some extend. This is the inability for modules to add their own
>> phases without doing changes to the axis2.xml.
>>
>> For e.g. Sandesha2 module expect to add its handlers to a custom phase
>> called 'RMPhase'. But since this cannot be added by itselt (for e.g.
>> by mentioning in the module.xml), users have to always edit the
>> axis2.xml file by hand and add this phase. This makes the task
>> difficult for users and is error prone.
>>
>> I believe it will be useful to make this feature available. My be we
>> can have a switch in axis2.xml which tells weather modules are allowed
>> to dynamically add their own phases or not.
>>
>> comments ... ?
>>
>>
>> Chamikara
>
>
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Chamikara Jayalath <ch...@gmail.com>.
Yep. I also prefer the other option (letting the module define its own
phases).
Chamikara
On 4/3/06, Eran Chinthaka <ch...@opensource.lk> wrote:
>
> Chamikara Jayalath wrote:
> > Hi Deepal,
> >
> > However, as you mentioned adding phases like RMPhase, SecurityPhase to
> > the default axis2.xml also solves the prolem.
>
> Irrespective of whether you have RM or not, you have an RMPhase ??
> Doesn't seem right to me. :(.
>
> -- Chinthaka
>
> >
> >
> > Chamikara
> >
> >
>
>
>
>
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Eran Chinthaka <ch...@opensource.lk>.
Chamikara Jayalath wrote:
> Hi Deepal,
>
> However, as you mentioned adding phases like RMPhase, SecurityPhase to
> the default axis2.xml also solves the prolem.
Irrespective of whether you have RM or not, you have an RMPhase ??
Doesn't seem right to me. :(.
-- Chinthaka
>
>
> Chamikara
>
>
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Deepal,
Even if the name of the new phase get mentioned in the module.xml, adding
the actual phase will be only be done by the Axis2 Deployment mechanism,
right ?
If so the Deployment Unit of Axis2 will exactly know the phases of the
system and their order. And it will know the state correctly.
However, as you mentioned adding phases like RMPhase, SecurityPhase to the
default axis2.xml also solves the prolem.
Chamikara
On 4/3/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi Chamikara
>
> I remember we had this discussion at the last f2f we had in Colombo and
> the final conclusion was not to allows module to add phases by itself.
> If some module require some specific phase then adding a phase is just
> a matter of changing the axis2.xml.
>
> I know if some one want to change axis2.xml in oder to deploy a module
> that is not a good idea and that break modulelarity of a module. There
> for my suggestion is we should treat module like Security , Sandesha
> separately and if they want some phase we should add them into
> default_axis2.xml
>
> I am +1 on supporting Sandesha , Security etc by default .
>
> And I dont like the idea of adding phases by module when they get
> initialize , that may lead system into unknown state , since no one know
> what we are going to have at the runtime.
>
>
> Chamikara Jayalath wrote:
>
> > Hi All,
> >
> > Phases are a nice feature in axis2 that is used by many module
> > authors. But there is a small defect in this that limits its usability
> > to some extend. This is the inability for modules to add their own
> > phases without doing changes to the axis2.xml.
> >
> > For e.g. Sandesha2 module expect to add its handlers to a custom phase
> > called 'RMPhase'. But since this cannot be added by itselt (for e.g.
> > by mentioning in the module.xml), users have to always edit the
> > axis2.xml file by hand and add this phase. This makes the task
> > difficult for users and is error prone.
> >
> > I believe it will be useful to make this feature available. My be we
> > can have a switch in axis2.xml which tells weather modules are allowed
> > to dynamically add their own phases or not.
> >
> > comments ... ?
> >
> >
> > Chamikara
>
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
Re: [Axis2] Giving modules the ability to define their own phases
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Chamikara
I remember we had this discussion at the last f2f we had in Colombo and
the final conclusion was not to allows module to add phases by itself.
If some module require some specific phase then adding a phase is just
a matter of changing the axis2.xml.
I know if some one want to change axis2.xml in oder to deploy a module
that is not a good idea and that break modulelarity of a module. There
for my suggestion is we should treat module like Security , Sandesha
separately and if they want some phase we should add them into
default_axis2.xml
I am +1 on supporting Sandesha , Security etc by default .
And I dont like the idea of adding phases by module when they get
initialize , that may lead system into unknown state , since no one know
what we are going to have at the runtime.
Chamikara Jayalath wrote:
> Hi All,
>
> Phases are a nice feature in axis2 that is used by many module
> authors. But there is a small defect in this that limits its usability
> to some extend. This is the inability for modules to add their own
> phases without doing changes to the axis2.xml.
>
> For e.g. Sandesha2 module expect to add its handlers to a custom phase
> called 'RMPhase'. But since this cannot be added by itselt (for e.g.
> by mentioning in the module.xml), users have to always edit the
> axis2.xml file by hand and add this phase. This makes the task
> difficult for users and is error prone.
>
> I believe it will be useful to make this feature available. My be we
> can have a switch in axis2.xml which tells weather modules are allowed
> to dynamically add their own phases or not.
>
> comments ... ?
>
>
> Chamikara
--
Thanks,
Deepal
................................................................
~Future is Open~