Hi Sanjiva, We were originally simply going to add a new phase into the outbound chain, but we realized that the OperationClients (e.g. the OutInAxisOperationClient) contain code that depends upon the EPRs being set to determine the transport, and in the case of a wire-level async req/rsp, to query the transport for the ReplyTo EPR. If we put the mechanism that David is talking about after the code in the OperationClients, then we'll run into difficulties (e.g. a request to generate a ReplyTo would most likely cause a listening port to be opened if one didn't already exist, which we of course wouldn't want to happen if the invocation was actually "local".)
If you want to suggest that the transport code be moved out to a separate phase in the chain, before which our phase could execute, then we'd happy to make that change instead. (This still leaves us potentially with some unnecessary cloning occurring in the AxisEngine since the handler chains may actually be altered , but I believe that we can deal with that later.) -Bill On Fri, 2006-07-21 at 23:15 +0530, Sanjiva Weerawarana wrote: > On Fri, 2006-07-21 at 17:04 +0100, David Illsley wrote: > > > So why dont you set the required transport out into options , and you > > > can do that as follows; > > > option.setTransportOut(TransportOutDescription transportOut). > > > > These absolutely are the properties that matter and it is easy for > > application to set them but I'm trying to allow the targeting to be > > transparent to the application such that they can set the destination EPR > > and the TargetResolver can realise that the service can be satisfied by > > another URI and rewrite the target EPR transparently. This code could be > > put in a handler which would work if the transport can't change but this > > precludes a local-optimisation (as by this point the listeners for an > > async invocation will already be set up for the http transport) and also > > precluses the idea of different handler chains based on different > > transports. > > This can be done with a straight module .. I'm still not clear why we > need to add a new programming model component for it. > > Why not just write a "router" module that does whatever function you > want and inserts handlers before/after/wherever it wants? Synapse for > example is capable of doing what you're looking for and it works simply > as a module - there was no need to introduce anything new. > > Sanjiva. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
