Simon,
On Tue, Feb 10, 2009 at 4:03 AM, Simon Nash <[email protected]> wrote: > Scott Kurz wrote: > >> I thought it was useful to point out that was specifically a problem w/ a >> callback over binding.sca, as the proxy set up for a binding.ws < >> http://binding.ws> (axis2) callback should be able to call back to the >> right client today, right? >> >> It shouldn't make any difference what the binding is. In all cases > the callback address is taken from the incoming message when the > proxy is created and injected, and this address is hard-wired into > the proxy. For a composite-scoped component, this will be the > callback address for whichever client did the first invocation on > the component, when the composite-scoped component implementation > instance was created. Subsequent invocations will not create and > reinject a new proxy. > > > > I agree that it shouldn't make any difference what the binding is, and also agree that the callback proxy would only be injected the first time a composite-scoped impl was invoked. I'm just saying that ideally the already-injected proxy would be able to do a late resolution of the actual endpoint. I believe this is how, say, the binding-ws-axis2 binding works (it looks at some WSA header on the incoming message and dynamically determines the callback endpoint) and also how I believe the JMS binding should work. So that's why I was arguing: isn't just this a limitation of the current binding.sca implementation? Scott
