On 3/30/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
If the Message.ENDPOINT_ADDRESS isn't stuffed into EndpointInfo.setAddress() in Client.invoke(), then the getConduit() will fail, not because the address is wrong, but more because "FOO" is a malformed URL string.
There isn't any real reason that we actually need to do new URL() in the constructor of the HTTPConduit. Looking at the HTTPConduit, it wouldn't hurt at all to delay it. The only place where we use the URL is to call toString() in setupURL and then when we close() the connection. Of course, ClientImpl.getConduit() could take cognizance of the
Message.ENDPOINT_ADDRESS override itself, but this I think would have the limitation that the override to a sane protocol could not be done by the application in a JAX-WS handler. That is, it have to be done upfront via ((BindingProviderproxy).getRequestContext().put(BindingProvider.ENDPOINT _ADDRESS_PROPERTY, "...") Which is I guess another reason for doing just-in-time Conduit retrieval, but that's a whole separate discussion :)
Couldn't we just retrieve a new Conduit in the MessageSenderInterceptor? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
