axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Grahn (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AXIS2-5267) Valid phase order configurations may result in invalid phase execution orders
Date Tue, 13 Mar 2012 16:04:47 GMT
Valid phase order configurations may result in invalid phase execution orders
-----------------------------------------------------------------------------

                 Key: AXIS2-5267
                 URL: https://issues.apache.org/jira/browse/AXIS2-5267
             Project: Axis2
          Issue Type: Bug
          Components: kernel
    Affects Versions: 1.5.4
            Reporter: James Grahn


The partial ordering of Axis2 handlers is not fully enforced.

Given a case with two handlers that ought to be run before a third, the system may fail as
implemented.

The current ordering system permits a configuration which is valid by inspection yet fails
to enforce the described order.   This property of the system emerges from both the configuration
and the time at which phase ordering is checked.

If my system relies on both A and B coming before C, I cannot state this dependency directly
(see AXIS2-5266).   However, I can invert this dependency and say A and B require C to follow.

Because phase rules are only checked at insertion time, if A and B are inserted first, they
are merely shifted to the beginning of the phase list (C is not yet present).   The resultant
phase list after the insertion of A and B might be: (B,A,X,Y,Z).

If C specifies that B comes before it in its rule (which is a valid, albeit incomplete requirement),
then C might be inserted immediately after B, resulting in this invalid phase ordering: (B,C,A,X,Y,Z).

This example of valid configuration yielding invalid phase ordering constitutes a defect in
the configuration.   

This defect could resolved by allowing the specification of multiple "before" and "after"
handlers (see AXIS2-5266), creating a dependency graph, and resolving a valid ordering from
the graph.   A dependency graph may also generalize many of the validation steps currently
performed into a cycle detection step.   (Even phasefirst and phaselast rules amount to cycle
detection if they are properly represented in the graph.)   A dependency graph would also
allow for confirmation that all dependencies are in place before a service is started.   

I believe this change would make the system more robust, and because the dependencies would
be resolved in a linear chain at service startup, there's no ongoing performance penalty for
creating/maintaining a more complex data structure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message