[
https://issues.apache.org/jira/browse/AXIS2-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen reopened AXIS2-4881:
------------------------------------
-1 for this change. Reasons:
1) In AddressingInHandler and AddressingOutHandler, the invoke method calls
invoke_stage1 and invoke_stage2, while in AbstractHandler it is invoke_stage2
that calls invoke. Maybe it's because I'm tired, but I'm unable to grasp the
logic behind that. For me this is more spaghetti than before.
2) The Phase class now explicitly checks if the Handler is a subclass of
AbstractHandler. That doesn't feel like good design to me. It also assumes that
Phase is the only class that will ever invoke a handler. Not sure if that is
true.
3) What you are trying to implement here is the "Template Method" pattern. It
is not possible to refactor AbstractHandler to implement that pattern properly
without breaking existing subclasses. Therefore the right solution is to leave
AbstractHandler as it is and implement that pattern in a subclass of
AbstractHandler. This class would have a final invoke method and two abstract
methods invoke_stage1 and invoke_stage2. This automatically solves issues 1 and
2.
4) invoke_stage1 and invoke_stage2 don't follow the generally accepted naming
conventions for Java methods.
5) Your argument for this change was that there a "number of handlers that have
a spaghetti code". If that was true, then I would have expected much larger
refactorings of the existing handlers. Since there are only minor changes in
these classes, I don't understand how the code could have been spaghetti before.
> Added invoke_stage1 and invoke_stage2 methods to AbstractHandler
> ----------------------------------------------------------------
>
> Key: AXIS2-4881
> URL: https://issues.apache.org/jira/browse/AXIS2-4881
> Project: Axis2
> Issue Type: Bug
> Reporter: Rich Scheuerle
> Assignee: Rich Scheuerle
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Background:
> The AbstractHandler class exposes an invoke() method that Handlers override
> to provide the specific invoke code.
> Problem:
> Many Handlers actually have 2 stages of logic. The first stage simply does
> some quick processing to determine if the handler should be called. The
> second stage does the actual work.
> Because there is only one invoke method, these separate stages of processing
> get lumped together.
> Solution:
> Provide an alternative (optional) invoke semantic.
> A Handler can choose to override the new invoke_stage1 and invoke_stage2
> methods.
> All current Handlers will continue to work. The existing invoke() method is
> retained.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
