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 Glen Daniels <gl...@thoughtcraft.com> on 2005/10/24 05:40:35 UTC
[axis2] Dispatchers
Hi folks!
A few comments about dispatchers/handlers:
* Does having an "AbstractDispatcher" class really help us in any way?
The only thing it really seems to do that's useful is the "relatesTo"
check... but shouldn't that check itself happen elsewhere (like in a
separate handler)? Right now if there are four dispatchers that all
inherit from AbstractDispatcher, the relatesTo check would happen four
times!
* 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. In line with
dispatchers just being handlers that live anywhere before (or in) the
dispach phase, I'd prefer to just put them in
org/apache/axis2/deployment/axis2.xml (as <handler> declarations) so
it's clear what's going on.
* Related to the above, wouldn't it be nice to have shortcut syntax like:
<phaseOrder type="inflow">
<phase name="First"/>
<phase name="Second">
<handler name="foo" class="MyHandler"/>
<handler name="bar" class="OtherHandler"/>
</phase>
</phaseOrder>
This would deploy foo and bar as the initial contents of the Second phase.
* Why do we have a separate "<dispatcherOrder>" element in axis2.xml,
when dispatchers are just handlers? Having separate ways to
deploy/configure handlers for specific functions (beyond putting them in
particular phases) seems bad. I'd prefer we put them in as <handler>
declarations per the above two comments.
Thoughts?
--Glen
Re: [axis2] Dispatchers
Posted by Srinath Perera <he...@gmail.com>.
Hi Glen, Deepal;
I think I am the one who hardcode the dispatchers in the first place.
But I am convinced
that it is a *bad* thing to do. I am +1 to add them all to the
dispatcher phase in the axis2.xml and let them be just Handlers
Thanks
Srinath
On 10/24/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Deepal:
>
> > I agree on that Dispatcher itself is a handler
>
> Ok.
>
> > 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).
>
> Ok.
>
> > 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.
>
> 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. To do this we either use current <handler> syntax:
>
> <handler name="MyDispatcher"
> class="package.MyDispatcher">
> <order phase="Dispatch"/>
> </handler>
>
> or my suggested simpler syntax:
>
> <phaseOrder>
> <phase name="Dispatch">
> <handler name="MyDispatcher"
> class="package.MyDispatcher"/>
> </phase>
> </phaseOrder>
>
> --Glen
>
Re: [axis2] Dispatchers
Posted by Deepal Jayasinghe <de...@opensource.lk>.
here is my +1
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@opensource.lk>
To: <di...@apache.org>
Cc: <ax...@ws.apache.org>
Sent: Wednesday, October 26, 2005 5:15 AM
Subject: Re: [axis2] Dispatchers
> On Tue, 2005-10-25 at 19:01 -0400, Davanum Srinivas wrote:
>> +1 from me. Glen please go ahead and clean it up :) I agree with the
>> principle, default should come from axis2.xml
>
> +1 from me too!
>
> Sanjiva.
>
>
>
Re: [axis2] Dispatchers
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-10-25 at 19:01 -0400, Davanum Srinivas wrote:
> +1 from me. Glen please go ahead and clean it up :) I agree with the
> principle, default should come from axis2.xml
+1 from me too!
Sanjiva.
Re: [axis2] Dispatchers
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me. Glen please go ahead and clean it up :) I agree with the
principle, default should come from axis2.xml
thanks,
dims
On 10/25/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> 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
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [axis2] Dispatchers
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Ruchith:
>>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?
>
> Are you talking about handlers in general?
> If so... I was under the impression that with Axis2 the users will NOT
> not have access to the handler chain, since we are using 'modules'.
> The module author is supposed to know where exactly to place the
> handler (configured using the module.xml in module.mar). Are we still
> going to stick only to this behavior or do we need to let the user
> configure the handler chain as in Axis1.x as well?
See my last msg to Deepal.
The handler author still needs to know exactly where to place the
handler regardless of whether you do it in axis2.xml, service.xml, or
module.xml. I'm not suggesting we break any rules; if two handlers both
say "I need to be first in the Dispatch phase", we have a conflict
regardless of where those handlers come from. I just think you should
be able to configure handlers directly without going through the work of
building a full-on Module if you want to.
--Glen
P.S. Speaking of conflicts, we need to eventually think about how to
resolve them without breaking things. In particular, it would be nice
if as a user, I could deploy two Modules that conflict (as described
above) and then resolve the conflict manually in my service.xml
*without* changing either module. This kind of thing is going to become
important because despite the best intentions of Module authors, you
can't account for interactions with other Modules/handlers that you
aren't aware of. Sometimes the guy who chooses to put Module A and
Module B together is the one who has to know how to make them work together.
Re: [axis2] Dispatchers
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi All,
Please see my commens below:
On 10/26/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> 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?
Are you talking about handlers in general?
If so... I was under the impression that with Axis2 the users will NOT
not have access to the handler chain, since we are using 'modules'.
The module author is supposed to know where exactly to place the
handler (configured using the module.xml in module.mar). Are we still
going to stick only to this behavior or do we need to let the user
configure the handler chain as in Axis1.x as well?
>
> I'm willing to do the work to code this up.
>
> --Glen
>
Thanks,
--
Ruchith
Re: [axis2] Dispatchers
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal:
> As I understand we came to a conclusion that the only way to deploy
> handlers using module. So if some one want to add a handler he has to
> create module and write it module.xml correctly and engage that module.
> (I know the fact that it make simple case harder). But I do not think we
> should go ahead and change axis2.xml to configure the handler chain (I
> do not know , the community has to take a decision).
I disagree with this notion, unfortunately. :( I think the original
idea behind Modules has gotten a little out of control....
Modules (i.e. *.mar with module.xml) should not, IMHO, be the *only* way
to deploy handlers (I believe I was the originator of the idea, and I
certainly did not intend that). It should also be trivial for someone
to write a handler that does something like logging or some kind of
message transformation and simply drop it in to the handler chain in a
known place using axis2.xml or service.xml.
Modules (again, IMHO) are not supposed to be a way to *restrict* usage,
they are supposed to be a way to *enable* better compositions of groups
of handlers. It's great that we can deploy a number of handlers that
have constrained relationships on execution order. But I don't
understand why that should *stop* someone from just deploying individual
handlers at will (subject to the same constraint validation rules).
Look at it this way - it's not as if you're even saying the user is
disallowed from deploying custom handlers at all. They're free to do
so... IF they're willing to make a module.xml and a .mar file/directory.
Well, if they're free to do it that way, why not let them do it
directly in axis2.xml or in service.xml for simplicity? Why would you
*not* want this?
> If there are some problems with phase lets us discuss that and finalize
> the stuff , I mean as I mentioned earlier I really do not like to give a
> way to configure handler chain in axis2.xml. That become minus point to
> axis2 , I mean current impl to deploy a module no need to modify any of
> the stuff , he just need to create a module and drop that into the
> module directory.
See above. I don't see a need to force people to do more work for the
simple case. This would be like saying you can't use directories on
your CLASSPATH, and you have to always jar up your classes (or worse
that you need to write a jar for each new class you want to add to the
classpath). Why not support both?
--Glen
Re: [axis2] Dispatchers
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi glen and all;
As I understand we came to a conclusion that the only way to deploy handlers
using module. So if some one want to add a handler he has to create module
and write it module.xml correctly and engage that module. (I know the fact
that it make simple case harder). But I do not think we should go ahead and
change axis2.xml to configure the handler chain (I do not know , the
community has to take a decision).
In the mean while we should minimize hard coding stuff , it should be as
much as configurable.
If there are some problems with phase lets us discuss that and finalize the
stuff , I mean as I mentioned earlier I really do not like to give a way to
configure handler chain in axis2.xml. That become minus point to axis2 , I
mean current impl to deploy a module no need to modify any of the stuff , he
just need to create a module and drop that into the module directory.
comments ...
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Glen Daniels" <gl...@thoughtcraft.com>
To: <ax...@ws.apache.org>
Sent: Wednesday, October 26, 2005 4:42 AM
Subject: Re: [axis2] Dispatchers
> 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
>
Re: [axis2] Dispatchers
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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
Re: [axis2] Dispatchers
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi
see my comments below;
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@opensource.lk>
To: <ax...@ws.apache.org>
Sent: Tuesday, October 25, 2005 9:05 AM
Subject: Re: [axis2] Dispatchers
> On Mon, 2005-10-24 at 12:46 -0400, Glen Daniels wrote:
>>
>> 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.
Any way at the deployment time , always load those order and populate
dispatching order using that.
>> To do this we either use current <handler> syntax:
>>
>> <handler name="MyDispatcher"
>> class="package.MyDispatcher">
>> <order phase="Dispatch"/>
>> </handler>
>>
>> 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.
>
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).
That is why I came up with <dispctchingOrder> XML syntax to order
dispatchers.
> Sanjiva.
>
>
>
Re: [axis2] Dispatchers
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2005-10-24 at 12:46 -0400, Glen Daniels wrote:
>
> 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?
> To do this we either use current <handler> syntax:
>
> <handler name="MyDispatcher"
> class="package.MyDispatcher">
> <order phase="Dispatch"/>
> </handler>
>
> 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.
Sanjiva.
Re: [axis2] Dispatchers
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Deepal:
> I agree on that Dispatcher itself is a handler
Ok.
> 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).
Ok.
> 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.
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. To do this we either use current <handler> syntax:
<handler name="MyDispatcher"
class="package.MyDispatcher">
<order phase="Dispatch"/>
</handler>
or my suggested simpler syntax:
<phaseOrder>
<phase name="Dispatch">
<handler name="MyDispatcher"
class="package.MyDispatcher"/>
</phase>
</phaseOrder>
--Glen
Re: [axis2] Dispatchers
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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" <gl...@thoughtcraft.com>
To: <ax...@ws.apache.org>
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
>
Re: [axis2] Dispatchers
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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