cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Why does ClientImpl.invoke() override the EndpointInfo address?
Date Fri, 30 Mar 2007 16:55:49 GMT
On 3/30/07, Glynn, Eoghan <eoghan.glynn@iona.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message