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 Srinath Perera <he...@gmail.com> on 2008/12/23 13:55:06 UTC
[Axis2]Proposal:Change to Handler order resolution Implementation
Hi All;
As far as I understood, with current handler order resolution in the
Phase (see org.apache.axis2.engine.Phase) the order of Handlers are
depended on the order they are added. For an example, if there are
handlers A and B and there is a rules in B says B after A, the order
is preserved only if B is added after A. if handlers are added B,A
then since A does not have rules, it is added to somewhere. AFAIK
current code only check rules for the new handler, but does not check
rules in the existing Handlers.
I noticed this problem while developing a Handler, and walk though the
code also verified it.
However, there is a standard way to solve this problem. The solution
is creating a graph assigning dependencies as edges in a graph--which
is a directed acyclic graph--and then doing a topology sort
http://en.wikipedia.org/wiki/Topological_sort . The algorithm takes
O(n) time and space where n is number of entities + number of rules,
which is pretty reasonable.
If people agree, I would like to redo the Handler resolution algorithm
in the Phase class with topology sort. Please comment. (Please note I
can not commit for a time line, but will do it when I get a free
time.)
Thanks very much
Srinath
--
============================
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Dec 24, 2008 at 1:10 AM, Srinath Perera <he...@gmail.com> wrote:
> > I am sorry Srinath if you get confused from my previous mail, I did not
> > tell we should not looking into what you mentioned. What I told was you
> > can get your handler resolution done with current impl.
>
> >
> > And I think what Amila did was something similar to what you mentioned.
> > As long as you do not break the current use cases, I have no problem of
> > tuning the handler resolution.
>
> Does Amila has a different implementation which does not merged with
> the current Head?
No. I just have mentioned a possible algorithm to do it.
thanks,
Amila.
I drew all conclusions looking at CVS head. If it is
> already done or somone doing it, so much the better :)
> Thanks
> Srinath
>
>
> --
> ============================
> Srinath Perera:
> Indiana University, Bloomington
> http://www.cs.indiana.edu/~hperera/<http://www.cs.indiana.edu/%7Ehperera/>
> http://www.bloglines.com/blog/hemapani
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Srinath Perera <he...@gmail.com>.
> I am sorry Srinath if you get confused from my previous mail, I did not
> tell we should not looking into what you mentioned. What I told was you
> can get your handler resolution done with current impl.
>
> And I think what Amila did was something similar to what you mentioned.
> As long as you do not break the current use cases, I have no problem of
> tuning the handler resolution.
Does Amila has a different implementation which does not merged with
the current Head? I drew all conclusions looking at CVS head. If it is
already done or somone doing it, so much the better :)
Thanks
Srinath
--
============================
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Deepal jayasinghe <de...@gmail.com>.
> Hi Deepal;
>
> I am not really worried about the above use case (I have already
> worked around this)--it was only a example.
>
> I come across this while working on something similar in my work,
> AFAIK this is "the way" to determine a total order from partial
> orders, and thought may be the algorithm is useful to Axis2 handler
> resolution as well. Point is this logic is pretty complex and very
> hard to get it right, and therefore using a well known algorithm
> helps.
>
> Anyway, there is nothing like working code, and if people are happy
> with current features we do not want to change it. I would not do it
> unless majority strongly think this should be done.
>
>
I am sorry Srinath if you get confused from my previous mail, I did not
tell we should not looking into what you mentioned. What I told was you
can get your handler resolution done with current impl.
And I think what Amila did was something similar to what you mentioned.
As long as you do not break the current use cases, I have no problem of
tuning the handler resolution.
Deepal
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Srinath Perera <he...@gmail.com>.
Hi Deepal;
I am not really worried about the above use case (I have already
worked around this)--it was only a example.
I come across this while working on something similar in my work,
AFAIK this is "the way" to determine a total order from partial
orders, and thought may be the algorithm is useful to Axis2 handler
resolution as well. Point is this logic is pretty complex and very
hard to get it right, and therefore using a well known algorithm
helps.
Anyway, there is nothing like working code, and if people are happy
with current features we do not want to change it. I would not do it
unless majority strongly think this should be done.
Thanks
Srinath
On Tue, Dec 23, 2008 at 2:11 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>
>> Hi All;
>>
>> As far as I understood, with current handler order resolution in the
>> Phase (see org.apache.axis2.engine.Phase) the order of Handlers are
>> depended on the order they are added. For an example, if there are
>> handlers A and B and there is a rules in B says B after A, the order
>> is preserved only if B is added after A. if handlers are added B,A
>> then since A does not have rules, it is added to somewhere. AFAIK
>> current code only check rules for the new handler, but does not check
>> rules in the existing Handlers.
>>
> hmm this can be easily solved by adding dependencies to both handlers,
> for example in handler A we can tell it needs to be after B, and B we
> can tell it needs to be before A. So you can get this easily done with
> current impl. I know which will not solve 100% of the problem, but the
> system is capable of handling that.
>
> One other suggestion wold be to add new phases and put the handler
> there, then that will make sure handlers are in order.
>> I noticed this problem while developing a Handler, and walk though the
>> code also verified it.
>>
>> However, there is a standard way to solve this problem. The solution
>> is creating a graph assigning dependencies as edges in a graph--which
>> is a directed acyclic graph--and then doing a topology sort
>> http://en.wikipedia.org/wiki/Topological_sort . The algorithm takes
>> O(n) time and space where n is number of entities + number of rules,
>> which is pretty reasonable.
>>
>> If people agree, I would like to redo the Handler resolution algorithm
>> in the Phase class with topology sort. Please comment. (Please note I
>> can not commit for a time line, but will do it when I get a free
>> time.)
>>
>>
> I am -0 on this, I know how many issues I have fixed alone the way
> specially in handlers and phases. You can see what we are doing is
> simple, but in different scenarios you have different issues, like
> engaging, dis-engaging and etc... Just because we have fixed so many
> issues I am nit going to tell that we should not make any changes, it is
> ok (and we should) do changes. But .... , if we have a way around to
> solve the problem then we should not take this as a high priority item.
>
> Adding something, the initial implementation of Axis2 did support what
> you ask for, but later we decided to change into this structure. And
> after implementation of Dynamic Phases most of the problem were able to
> solve very easily. Even your problem can be easily solve with that.
>
> Thanks
> Deepal
>> Thanks very much
>> Srinath
>>
>>
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
> http://deepal.org
>
>
--
============================
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Deepal jayasinghe <de...@gmail.com>.
> Hi All;
>
> As far as I understood, with current handler order resolution in the
> Phase (see org.apache.axis2.engine.Phase) the order of Handlers are
> depended on the order they are added. For an example, if there are
> handlers A and B and there is a rules in B says B after A, the order
> is preserved only if B is added after A. if handlers are added B,A
> then since A does not have rules, it is added to somewhere. AFAIK
> current code only check rules for the new handler, but does not check
> rules in the existing Handlers.
>
hmm this can be easily solved by adding dependencies to both handlers,
for example in handler A we can tell it needs to be after B, and B we
can tell it needs to be before A. So you can get this easily done with
current impl. I know which will not solve 100% of the problem, but the
system is capable of handling that.
One other suggestion wold be to add new phases and put the handler
there, then that will make sure handlers are in order.
> I noticed this problem while developing a Handler, and walk though the
> code also verified it.
>
> However, there is a standard way to solve this problem. The solution
> is creating a graph assigning dependencies as edges in a graph--which
> is a directed acyclic graph--and then doing a topology sort
> http://en.wikipedia.org/wiki/Topological_sort . The algorithm takes
> O(n) time and space where n is number of entities + number of rules,
> which is pretty reasonable.
>
> If people agree, I would like to redo the Handler resolution algorithm
> in the Phase class with topology sort. Please comment. (Please note I
> can not commit for a time line, but will do it when I get a free
> time.)
>
>
I am -0 on this, I know how many issues I have fixed alone the way
specially in handlers and phases. You can see what we are doing is
simple, but in different scenarios you have different issues, like
engaging, dis-engaging and etc... Just because we have fixed so many
issues I am nit going to tell that we should not make any changes, it is
ok (and we should) do changes. But .... , if we have a way around to
solve the problem then we should not take this as a high priority item.
Adding something, the initial implementation of Axis2 did support what
you ask for, but later we decided to change into this structure. And
after implementation of Dynamic Phases most of the problem were able to
solve very easily. Even your problem can be easily solve with that.
Thanks
Deepal
> Thanks very much
> Srinath
>
>
--
Thank you!
http://blogs.deepal.org
http://deepal.org
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Deepal jayasinghe <de...@gmail.com>.
Amila Suriarachchi wrote:
>
>
> On Tue, Dec 23, 2008 at 6:25 PM, Srinath Perera <hemapani@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi All;
>
> As far as I understood, with current handler order resolution in the
> Phase (see org.apache.axis2.engine.Phase) the order of Handlers are
> depended on the order they are added. For an example, if there are
> handlers A and B and there is a rules in B says B after A, the order
> is preserved only if B is added after A. if handlers are added B,A
> then since A does not have rules, it is added to somewhere. AFAIK
> current code only check rules for the new handler, but does not check
> rules in the existing Handlers.
>
> I noticed this problem while developing a Handler, and walk though the
> code also verified it.
>
> However, there is a standard way to solve this problem. The solution
> is creating a graph assigning dependencies as edges in a graph--which
> is a directed acyclic graph--and then doing a topology sort
> http://en.wikipedia.org/wiki/Topological_sort . The algorithm takes
> O(n) time and space where n is number of entities + number of rules,
> which is pretty reasonable.
>
> If people agree, I would like to redo the Handler resolution algorithm
> in the Phase class with topology sort. Please comment. (Please note I
> can not commit for a time line, but will do it when I get a free
> time.)
>
>
> This was discuss sometime back please see here[1],[2]. I developed a
> simple algorithm[3] at the time
> this disscussion happen to resolve the phases.
> +1 to add this feature using any algorithm.
>
Exactly, as I remember correct solution was to implement the phase
resolving and dynamic phases.
Deepal
Re: [Axis2]Proposal:Change to Handler order resolution Implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Dec 23, 2008 at 6:25 PM, Srinath Perera <he...@gmail.com> wrote:
> Hi All;
>
> As far as I understood, with current handler order resolution in the
> Phase (see org.apache.axis2.engine.Phase) the order of Handlers are
> depended on the order they are added. For an example, if there are
> handlers A and B and there is a rules in B says B after A, the order
> is preserved only if B is added after A. if handlers are added B,A
> then since A does not have rules, it is added to somewhere. AFAIK
> current code only check rules for the new handler, but does not check
> rules in the existing Handlers.
>
> I noticed this problem while developing a Handler, and walk though the
> code also verified it.
>
> However, there is a standard way to solve this problem. The solution
> is creating a graph assigning dependencies as edges in a graph--which
> is a directed acyclic graph--and then doing a topology sort
> http://en.wikipedia.org/wiki/Topological_sort . The algorithm takes
> O(n) time and space where n is number of entities + number of rules,
> which is pretty reasonable.
>
> If people agree, I would like to redo the Handler resolution algorithm
> in the Phase class with topology sort. Please comment. (Please note I
> can not commit for a time line, but will do it when I get a free
> time.)
This was discuss sometime back please see here[1],[2]. I developed a simple
algorithm[3] at the time
this disscussion happen to resolve the phases.
+1 to add this feature using any algorithm.
thanks,
Amila.
[1]http://marc.info/?l=axis-user&m=119868574526115&w=2
[2]http://marc.info/?l=axis-dev&m=119746274128710&w=2
[3]http://issues.apache.org/jira/browse/AXIS2-3421
>
>
> Thanks very much
> Srinath
>
> --
> ============================
> Srinath Perera:
> Indiana University, Bloomington
> http://www.cs.indiana.edu/~hperera/<http://www.cs.indiana.edu/%7Ehperera/>
> http://www.bloglines.com/blog/hemapani
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/