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" <[EMAIL PROTECTED]>
To: <[email protected]>
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
