Hi All, Please see my commens below:
On 10/26/05, Glen Daniels <[EMAIL PROTECTED]> 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
