Hi Glen;
I agree on that Dispatcher itself is a handler
but the name "Dispatcher" implies different meaning than a handler , it is
obvious that a module can configure to put handlers into Dispatch phase we
are not avoiding doing that (in fact I did the same thing to a the SypaseToy
that I wrote , I put just a handler into Dispatch phase as its phase first
handler and which will do the dispatching).
But If some one to add dispatcher as a dispatcher not as a handler , we have
give them a indirect path to do so (<dispatchingOrder> in axis2.xml) , and
configure the order they want. Since Axis2 has hard coded the dispatching
order. There can be some users who want to run URLDispatcher after
AddressingDisptcher , since we have hard coded the dispatching order no one
can change the order, therefore only way to do that by giving a way to
change that , that is why I came up with that XML element. So if user wants
to override he can put that XML element and do so , if not the default order
will work nicely. I know that 99% of the time no one go and change that. So
most of the time AxisConfigurationImpl.setDefaultDispatchers() method will
be invoked.
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Glen Daniels" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 24, 2005 9:52 AM
Subject: Re: [axis2] Dispatchers
Glen Daniels wrote:
* I don't like having the default dispatchers be deployed in a way that
causes them NOT to appear in the standard axis2.xml file.
To be clear here, I'm talking about
AxisConfigurationImpl.setDefaultDispatchers()...
The basic idea of that whole message is that there's no such thing as a
"dispatcher"... it's not important WHO sets the serviceDescription and the
operationDescription in the MessageContext - and in fact, it could even be
the transport receiver itself! What's important is that at the end of the
"dispatch" *phase*, they have been set.
--G
