Scott Kurz wrote:
Simon,
Just trying to educate myself here...
On Tue, Feb 10, 2009 at 10:27 AM, Simon Nash <[email protected]
<mailto:[email protected]>> wrote:
For binding-ws-axis2, the callback endpoint from the input message
is resolved at the time the proxy is created, not at the time the
proxy is called. This approach is used for all binding types.
So in Axis2ServiceProvider.invokeTarget, isn't this code:
SOAPHeader header = inMC.getEnvelope().getHeader();
if (header != null) {
OMElement from = header.getFirstChildWithName(QNAME_WSA_FROM);
if (from != null) {
OMElement callbackAddrElement =
from.getFirstChildWithName(QNAME_WSA_ADDRESS);
if (callbackAddrElement != null) {
if
(contract.getInterfaceContract().getCallbackInterface() != null) {
callbackAddress = callbackAddrElement.getText();
}
}
doing what I was describing, i.e. dynamically calculating the callback
address?
This code is taking the callback address off the wire and putting it
in the thread context message. This happens for every inbound request.
When the callback proxy is created and injected, it takes the
callback address out of the thread context message and puts it
into the proxy. At that time it's hard-wired into the callback
proxy and will always be used for calls through that proxy.
So wouldn't a composite-scoped impl using binding-ws-axis2 for both
forward and callback directions be able to dynamically callback to the
correct endpoint?
No, because the proxy endpoint was hard-wired when the proxy
was created. The above code isn't used when the proxy makes an
outbound call. It's only used for inbound calls.
Simon
Is my over-simplification the assumption that the callback uses
<binding.ws <http://binding.ws>> just because the forward direction uses
this binding?
(So the code I pasted would only be one of the 'simple' cases you
mentioned?)
Thanks,Scott
