ok, users do not change the dispatcers frquesntly. So we do not need a seperate Dispatcher, and just having a handler will be good enough ..
But right now we have hardcoded some dispatchers in the source code .. maybe we should take them to the axis2.xml Srinath On 8/25/05, Glen Daniels <[EMAIL PROTECTED]> wrote: > Hi all: > > Srinath Perera wrote: > > I agree with ruchith somewhat, since the URL, the > > "RequestURIBasedDispatcher" would operates on, is not usually > > encrypted (not in the domein of WS security .. right?) so it can (at > > least in theory) could work before the security Handler! > > Right - same with SOAPAction-based dispatch, or anything else outside > the SOAP envelope (i.e. transport-specific). > > > 1) But do we need a DispatchPhaseOne .. why d'not we use the phase > > first ect to order them (rules phaseFirst functional?) > > Why? > > > 2) we need to find some way to make the Dispatchers configurable via > > the axis2.xml .. how about adding a <dispatcher ...> tag and put all > > our defult dispatchers in to axis2.xml > > Hm - isn't a "dispatcher" just any old Handler that happens to know how > to set the service/operation/messageReference? It's not (and shouldn't > be) anything different or special.... If you make a special class of > "dispatchers" you then need to define the meaning of that, extra > semantics, etc., none of which I believe is necessary. > > I think the only thing that matters is that at the end of the Dispatch > phase, the post-condition must be met. The whole point is to allow > maximal flexibility in terms of how and when that might occur. > > --Glen >
