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 Deepal Jayasinghe <de...@gmail.com> on 2007/12/26 17:15:10 UTC
[Axis2] Dynamic Phase support
Hi all,
I just implemented and commit the initial implementation of the
dynamic phase support which we argued a lot in the mailing list over
the last few weeks. The implementation which I did is not that complex
but I hope that will be enough for most of the scenarios we discussed.
Anyway if a module author want to add a new phase without changing
axis2.xml then (s)he can do that be adding following element into
module.xml (multiple entries if he want to add many phases) .
<phase name="Foo" after="After_phase_Name" before="Before_Phase_Name"
flow="[InFlow,OutFlow,OutFaultFlow,InFaultFlow]"/>
Here the name of the phase is the phase we want to add , and before
and after values can be used to tell where to put the phase , however
one of them can be null. And the flow attribute tell which flow we
need to add the phase. There one thing we need to remember here is
that , it is always recommended to use the phase name of the before
and after as the phase names in axis2.xml. Because if you try to
depend on someone else , that might not work and if the module is not
deployed.
Whether the module is going to engage or not if you have add a new
phase that phase will be added to the chain.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Damitha:
> Because I think currently the phases in Axis2 is not a totally ordered
> set like integers you took for your example. ie. There could be two
> phases which have no binary relationship(using before, after) with each
> other. But at the same time as Glen mentioned, if he want to make the
> phases in axis2 a total order then it is redundant in saying
> <phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
> because MyNewPhase, phase2 and phase3 should relate to each other in a
> total ordering.
The only relationship (without more information) that phase2 and phase3
have here is that they must both be after MyNewPhase.
> But I don't think the phases need a total ordering because we should
> always be able to define a phase which have no before, after relation
> ship with some other phases. That means it don't care about when it's
> handers are executed in the phase order in relation to certain phases.
If you give the following constraints (all of them are "before"s but
they could just as well be reversed as "after"s)...
A before B
1 before B
B before C
B before 2
You should end up with a list in the order [A 1] B [C 2]. The order of
A and 1 doesn't matter as long as they are both before B, ditto with C
and 2 as long as they are both after B.
A before B
A before 1
B before C
B before 2
1 before 2
This could give you A 1 B C 2, A B C 1 2, A B 1 2 C, etc.
In other words, partial ordering between sets of elements connected by
constraints - (A B C) (A 1 2) (B 2) - MUST be respected, and any total
order which does so is fine.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Damitha Kumarage <da...@gmail.com>.
Hi Deepal,
Deepal Jayasinghe wrote:
>On 12/26/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
>
>>Deepal Jayasinghe wrote:
>>
>>
>>>I just implemented and commit the initial implementation of the
>>>dynamic phase support
>>>
>>>
>>:(
>>
>>I mentioned that I was working on this, didn't I? [1] It's always
>>unfortunate when there's duplicated work. If I'd known you were
>>planning to work on it, one of us could have saved some time or we could
>>have worked together to spec it out.
>>
>>
>
>I did not plan to do that , however I got some free time and
>implemented that since we discussed that and wanted to have that for
>next release. And believe me it did not take that much of time it was
>less than 1 and half hours. So I commit the code and I do not see any
>problem with that ( I mean and any duplicate of work) . My work going
>to be duplicate if you have commit the code.
>
>
>
>>I'll review your implementation, Deepal, but I think I want a little
>>more functionality. For instance, there may be multiple before/after
>>phases - if my phase needs to be before phase2 AND before phase3,
>>
>>
>
>what do you mean by this ?
>
>this is like I need to find a number which is less than 3 as well as
>less than 2 , and that can be simplified to I need to find a number
>which is less than 2 . So why do you want to have two before phases.
>
>
Because I think currently the phases in Axis2 is not a totally ordered
set like integers you took for your example. ie. There could be two
phases which have no binary relationship(using before, after) with each
other. But at the same time as Glen mentioned, if he want to make the
phases in axis2 a total order then it is redundant in saying
<phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
because MyNewPhase, phase2 and phase3 should relate to each other in a
total ordering.
But I don't think the phases need a total ordering because we should
always be able to define a phase which have no before, after relation
ship with some other phases. That means it don't care about when it's
handers are executed in the phase order in relation to certain phases.
thanks
Damitha
>And I do not think any one will look for such kind of complex use case
>, I know you can come up with one , but in Axis2 mailing list no one
>has ever asked for such kind of feature.
>
>
>
>>to be able to specify something like:
>>
>><phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
>>
>>
>
>I agree that some one can tell that he need to add the phase to both
>in and out flow , and that will be a simple fix to my implementation.
>
>
>>Also, my implementation so far handles resolving constraints even after
>>a module has been deployed, so if one module has the above phase
>>declaration and there isn't a "phase2" yet, when the next module gets
>>deployed and defines "phase2", it will try to put it after "MyNewPhase"
>>(if it can't that's an error of course). This means that some orderings
>>for module deployment might not work, but we can grow the (currently
>>very simple) logic into a more complex total-ordering system if we need to.
>>
>>
>
>Let's implement this only if some USER ask for this :) , this is more
>work than any kind of user want.
>
>
>
>>I'll get my stuff checked in ASAP, but if you're planning to do more
>>work in this area, please let me know beforehand?
>>
>>
>Nope I am not going to do any more changes.
>
>
>Thanks
>Deepal
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Deepal Jayasinghe <de...@gmail.com>.
On 12/26/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Deepal Jayasinghe wrote:
> > I just implemented and commit the initial implementation of the
> > dynamic phase support
>
> :(
>
> I mentioned that I was working on this, didn't I? [1] It's always
> unfortunate when there's duplicated work. If I'd known you were
> planning to work on it, one of us could have saved some time or we could
> have worked together to spec it out.
I did not plan to do that , however I got some free time and
implemented that since we discussed that and wanted to have that for
next release. And believe me it did not take that much of time it was
less than 1 and half hours. So I commit the code and I do not see any
problem with that ( I mean and any duplicate of work) . My work going
to be duplicate if you have commit the code.
>
> I'll review your implementation, Deepal, but I think I want a little
> more functionality. For instance, there may be multiple before/after
> phases - if my phase needs to be before phase2 AND before phase3,
what do you mean by this ?
this is like I need to find a number which is less than 3 as well as
less than 2 , and that can be simplified to I need to find a number
which is less than 2 . So why do you want to have two before phases.
And I do not think any one will look for such kind of complex use case
, I know you can come up with one , but in Axis2 mailing list no one
has ever asked for such kind of feature.
> to be able to specify something like:
>
> <phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
I agree that some one can tell that he need to add the phase to both
in and out flow , and that will be a simple fix to my implementation.
>
> Also, my implementation so far handles resolving constraints even after
> a module has been deployed, so if one module has the above phase
> declaration and there isn't a "phase2" yet, when the next module gets
> deployed and defines "phase2", it will try to put it after "MyNewPhase"
> (if it can't that's an error of course). This means that some orderings
> for module deployment might not work, but we can grow the (currently
> very simple) logic into a more complex total-ordering system if we need to.
Let's implement this only if some USER ask for this :) , this is more
work than any kind of user want.
>
> I'll get my stuff checked in ASAP, but if you're planning to do more
> work in this area, please let me know beforehand?
Nope I am not going to do any more changes.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal, all:
Deepal Jayasinghe 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.
For now, I agree. However, we should a) integrate trimmed-down
axis2.xmls into our tests once we're solid with the dynamic phase code,
and b) plan to trim the default axis2.xml in a while, after a couple of
releases each of the standard modules.
Re: adding duplicate phases, the model in the code I'm currently working
with supports multiple additions of the same thing - it simply merges
the constraints together. So if there's a statically defined phase
"Foo" that's after the "Transport" phase, and a module then tries to
deploy "Foo BEFORE Transport" there will be an error. However if the
module deployed "Foo" with no constraints or with "AFTER Transport" no
problem.
Amila, in answer to your question about addressing, modules add handlers
to the phases they want. Adding handlers to non-existent phases is an
error for now. So in a world where the Addressing phase is not in the
axis2.xml, if you tried to engage Sandesha without also engaging
Addressing, you'd get an error. But as long as Addressing was also
engaged, you'd be fine (since it would deploy the Addressing phase).
Thanks,
--Glen
>
> -Deepal
>
> On 12/28/07, Amila Suriarachchi <am...@gmail.com> wrote:
>> On Dec 27, 2007 9:38 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
>>
>>> On 12/27/07, David Illsley <da...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by 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.
Re: [Axis2] Dynamic Phase support
Posted by Amila Suriarachchi <am...@gmail.com>.
hi deepal,
As I have said in my previous mail, I am not saying we MUST do it. Basically
I have given my thoughts
regarding the dynamic phases. As you have told if some one going to add it
to Axis2 2.x. :)
As I have told earlier as well I am ok with going to Axis2 1.4 with either
only static phases or
with the improvement you have done.
thanks,
Amila.
On Jan 2, 2008 9:33 AM, Deepal jayasinghe <de...@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?
> >
> Well we should not forget that we have release Axis2 1.3 and doing such
> a major changes after that kind of release is not good thing. And we
> should not forget about the backward compatibility. I have no object of
> doing that if we have not done Axis2 1.0 and Axis2 is not in production.
>
> The major problem I saw here is users are expecting fixes to be in the
> next release but will they use than when there are a number of such
> critical changes. So I am +1 on keeping what we have now (no changes to
> Axis2.xml) and have the dynamic phase support if someone want to add a
> new phases. Second if we are going to change this kind of changes let's
> do Axis2 2.0 not 1.4.
> > 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.
> :) , why not if they want they will change axis2.xml or if they like
> they will use dynamic phases.
> > This
> > is the main idea of going for dynamic phases.
> Nope .
> > 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.
> >
> yes , if that is the case we can remove security phase from axis2.xml. I
> am -1 on removing Dispatch phase and other predefined phases from
> axis2.xml (I am sorry for my -1)
> > 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.
> Yes whole idea of Dynamic phases confuse both the run time and the
> system administrators :)
> That is why I still think if we want to add a new phase need to change
> axis2.xml :)
> > 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.
> >
> Nope , let's remove all of them
> > Therefore I think better to have either dynamic phases or static
> > phases rather than both.
> may be but I am -1 on removing the phase from axis2.xml
>
> -Deepal
>
> ---------------------------------------------------------------------
> 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.
RE: [Axis2] Dynamic Phase support
Posted by Tom Jordahl <tj...@adobe.com>.
I support Deepal's desire to maintain a stable 1.x release stream. I
think he is right on the money with the "add new feature, leave existing
stuff alone".
Dynamic phases seem like they might be useful for some things (Rampart),
but just reading the design discussion makes my head hurt and will be
*really* confusing to users.
--
Tom Jordahl
-----Original Message-----
From: Deepal jayasinghe [mailto:deepalk@gmail.com]
Sent: Tuesday, January 01, 2008 11:04 PM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Dynamic Phase support
> 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?
>
Well we should not forget that we have release Axis2 1.3 and doing such
a major changes after that kind of release is not good thing. And we
should not forget about the backward compatibility. I have no object of
doing that if we have not done Axis2 1.0 and Axis2 is not in production.
The major problem I saw here is users are expecting fixes to be in the
next release but will they use than when there are a number of such
critical changes. So I am +1 on keeping what we have now (no changes to
Axis2.xml) and have the dynamic phase support if someone want to add a
new phases. Second if we are going to change this kind of changes let's
do Axis2 2.0 not 1.4.
> 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.
:) , why not if they want they will change axis2.xml or if they like
they will use dynamic phases.
> This
> is the main idea of going for dynamic phases.
Nope .
> 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.
>
yes , if that is the case we can remove security phase from axis2.xml. I
am -1 on removing Dispatch phase and other predefined phases from
axis2.xml (I am sorry for my -1)
> 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.
Yes whole idea of Dynamic phases confuse both the run time and the
system administrators :)
That is why I still think if we want to add a new phase need to change
axis2.xml :)
> 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.
>
Nope , let's remove all of them
> Therefore I think better to have either dynamic phases or static
> phases rather than both.
may be but I am -1 on removing the phase from axis2.xml
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Deepal jayasinghe <de...@gmail.com>.
> 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?
>
Well we should not forget that we have release Axis2 1.3 and doing such
a major changes after that kind of release is not good thing. And we
should not forget about the backward compatibility. I have no object of
doing that if we have not done Axis2 1.0 and Axis2 is not in production.
The major problem I saw here is users are expecting fixes to be in the
next release but will they use than when there are a number of such
critical changes. So I am +1 on keeping what we have now (no changes to
Axis2.xml) and have the dynamic phase support if someone want to add a
new phases. Second if we are going to change this kind of changes let's
do Axis2 2.0 not 1.4.
> 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.
:) , why not if they want they will change axis2.xml or if they like
they will use dynamic phases.
> This
> is the main idea of going for dynamic phases.
Nope .
> 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.
>
yes , if that is the case we can remove security phase from axis2.xml. I
am -1 on removing Dispatch phase and other predefined phases from
axis2.xml (I am sorry for my -1)
> 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.
Yes whole idea of Dynamic phases confuse both the run time and the
system administrators :)
That is why I still think if we want to add a new phase need to change
axis2.xml :)
> 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.
>
Nope , let's remove all of them
> Therefore I think better to have either dynamic phases or static
> phases rather than both.
may be but I am -1 on removing the phase from axis2.xml
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Amila Suriarachchi <am...@gmail.com>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by David Illsley <da...@gmail.com>.
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 <gl...@thoughtcraft.com> 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 <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
> >>
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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 <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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by David Illsley <da...@gmail.com>.
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 <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
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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
Re: [Axis2] Dynamic Phase support
Posted by Deepal Jayasinghe <de...@gmail.com>.
On 12/29/07, Amila Suriarachchi <am...@gmail.com> wrote:
> On Dec 28, 2007 9:24 PM, Deepal Jayasinghe <de...@gmail.com> 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?
Amila ,
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 ?
>
> I think before doing any implementation we need to come to an agreement with
> what we expect as the dynamic phase support.
+1
>
> 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.
So with my changes user can define phases in module.xml , if he want
to add a new phase. Then he does not need to change axis2.xml
>
> 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.
>
> 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.
I think this is too much of work to do at this point , since Axis2 is
in production .
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 28, 2007 9:24 PM, Deepal Jayasinghe <de...@gmail.com> 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 <am...@gmail.com> wrote:
> > On Dec 27, 2007 9:38 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
> >
> > > On 12/27/07, David Illsley <da...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
> >
>
>
> --
>
>
>
>
>
> ============================
> Deepal Jayasinghe
> Lanka Software Foundation
>
> ---------------------------------------------------------------------
> 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.
Re: [Axis2] Dynamic Phase support
Posted by Deepal Jayasinghe <de...@gmail.com>.
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.
-Deepal
On 12/28/07, Amila Suriarachchi <am...@gmail.com> wrote:
> On Dec 27, 2007 9:38 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
>
> > On 12/27/07, David Illsley <da...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
--
============================
Deepal Jayasinghe
Lanka Software Foundation
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 27, 2007 9:38 PM, Deepal Jayasinghe <de...@gmail.com> wrote:
> On 12/27/07, David Illsley <da...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] Dynamic Phase support
Posted by Deepal Jayasinghe <de...@gmail.com>.
On 12/27/07, David Illsley <da...@gmail.com> 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.
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by David Illsley <da...@gmail.com>.
Glen,
It's just as well I saw you volunteering and didn't do it as well,
'cos I was tempted :-)
+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?
David
On Dec 26, 2007 4:33 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Deepal Jayasinghe wrote:
> > I just implemented and commit the initial implementation of the
> > dynamic phase support
>
> :(
>
> I mentioned that I was working on this, didn't I? [1] It's always
> unfortunate when there's duplicated work. If I'd known you were
> planning to work on it, one of us could have saved some time or we could
> have worked together to spec it out.
>
> I'll review your implementation, Deepal, but I think I want a little
> more functionality. For instance, there may be multiple before/after
> phases - if my phase needs to be before phase2 AND before phase3, I want
> to be able to specify something like:
>
> <phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
>
> Also, my implementation so far handles resolving constraints even after
> a module has been deployed, so if one module has the above phase
> declaration and there isn't a "phase2" yet, when the next module gets
> deployed and defines "phase2", it will try to put it after "MyNewPhase"
> (if it can't that's an error of course). This means that some orderings
> for module deployment might not work, but we can grow the (currently
> very simple) logic into a more complex total-ordering system if we need to.
>
> I'll get my stuff checked in ASAP, but if you're planning to do more
> work in this area, please let me know beforehand?
>
> Thanks,
> --Glen
>
> [1]
> http://www.nabble.com/Re%3A--AXIS2--Adding-security-phase-to-OutFaultFlow-p14420050.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Deepal Jayasinghe wrote:
> I just implemented and commit the initial implementation of the
> dynamic phase support
:(
I mentioned that I was working on this, didn't I? [1] It's always
unfortunate when there's duplicated work. If I'd known you were
planning to work on it, one of us could have saved some time or we could
have worked together to spec it out.
I'll review your implementation, Deepal, but I think I want a little
more functionality. For instance, there may be multiple before/after
phases - if my phase needs to be before phase2 AND before phase3, I want
to be able to specify something like:
<phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
Also, my implementation so far handles resolving constraints even after
a module has been deployed, so if one module has the above phase
declaration and there isn't a "phase2" yet, when the next module gets
deployed and defines "phase2", it will try to put it after "MyNewPhase"
(if it can't that's an error of course). This means that some orderings
for module deployment might not work, but we can grow the (currently
very simple) logic into a more complex total-ordering system if we need to.
I'll get my stuff checked in ASAP, but if you're planning to do more
work in this area, please let me know beforehand?
Thanks,
--Glen
[1]
http://www.nabble.com/Re%3A--AXIS2--Adding-security-phase-to-OutFaultFlow-p14420050.html
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] Dynamic Phase support
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Deepal Jayasinghe wrote:
> I just implemented and commit the initial implementation of the
> dynamic phase support
:(
I mentioned that I was working on this, didn't I? [1] It's always
unfortunate when there's duplicated work. If I'd known you were
planning to work on it, one of us could have saved some time or we could
have worked together to spec it out.
I'll review your implementation, Deepal, but I think I want a little
more functionality. For instance, there may be multiple before/after
phases - if my phase needs to be before phase2 AND before phase3, I want
to be able to specify something like:
<phase name="MyNewPhase" before="phase2,phase3" flow="in,out"/>
Also, my implementation so far handles resolving constraints even after
a module has been deployed, so if one module has the above phase
declaration and there isn't a "phase2" yet, when the next module gets
deployed and defines "phase2", it will try to put it after "MyNewPhase"
(if it can't that's an error of course). This means that some orderings
for module deployment might not work, but we can grow the (currently
very simple) logic into a more complex total-ordering system if we need to.
I'll get my stuff checked in ASAP, but if you're planning to do more
work in this area, please let me know beforehand?
Thanks,
--Glen
[1]
http://www.nabble.com/Re%3A--AXIS2--Adding-security-phase-to-OutFaultFlow-p14420050.html
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org