Hi Deepal, Sanjiva:
What I'm trying to say is that we should NOT hard-code the dispatch
order, we should have it simply exist as configuration in the default
axis2.xml file.
+1 .. Deepal what's the advantage of having it fixed programmatically
instead of being read in from the config?
In the first place we did not think that we want to change Dispatching
order, but when it come to WS-S we realized that there are instance that
require different dispatching order.
And in the mean while 99% of the time no one is going to change the
order so its worth to hard code that.
-1 from me on that one. Putting it in the config as a simple handler
ordering thing just like any other seems to make so much more sense! If
you don't want to change it, then there's no problem, it'll work in the
default way. If you *do* want to change it, it's obvious how to do it
and there aren't two ways of doing the same thing. I also think
hard-coding this stuff makes it confusing when you look at axis2.xml
(not everything is "really" there).
We have a great mechanism for deploying and ordering handlers -
dispatchers are nothing special, they are just handlers - so why not use it?
> [...]
or my suggested simpler syntax:
<phaseOrder>
<phase name="Dispatch">
<handler name="MyDispatcher"
class="package.MyDispatcher"/>
</phase>
</phaseOrder>
Does the latter syntax imply we can remove the first form? If so +1 for
the latter otherwise I don't think we need alternate syntax for this
type of stuff because changing dispatchers type work is not a regular
user activity .. or even close to it.
(responding to Sanjiva) This isn't about dispatchers alone, this is
about handlers in general. The idea is that the user might want to put
particular handlers into a Phase as the "default contents" of that
Phase. The above is a quick + clean syntax for doing that.
You *also* need the other syntax because you might be deploying handlers
in a module.xml, when the Phases have already been defined and populated
and you're just adding to the existing list. It's possible we could
accept only the phase-based syntax in axis2.xml and both in module.xml,
but I think both should be usable anywhere.
In the second approach it leads to configure handler chain using
axis2.xml , I mean we have no control over avoiding that if we give that
flexibility. And other thing is though Dispatcher is a handler , it can
not override invoke() method (if it extend from AbstarctDispatcher) so
we have to treat dispatcher as a dispatcher (there are some logic that
need to be there).
See my original message on this thread - first, I don't see a need for
AbstractDispatcher at all. Second, when deploying a handler it doesn't
matter how that class is built as long as it implements Handler, so you
could still freely use the current "dispatchers" as normal handlers.
I very much like the ability to quickly configure the handler chain
using axis2.xml. As long as nothing creates conflicts, why shouldn't we
allow this?
I'm willing to do the work to code this up.
--Glen
