You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Glynn, Eoghan" <eo...@iona.com> on 2007/03/30 14:53:06 UTC
Why does ClientImpl.invoke() override the EndpointInfo address?
Folks,
Does anyone know why ClientImpl.invoke() overrides the EndpointInfo
address with the Message.ENDPOINT_ADDRESS property?
This has the effect of making permanent any application-level overriding
of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY. By permanent, I mean
applying to all subsequent invocations on this proxy, not just the
current one.
This doesn't seem correct to me, as I'd expect it to be a one-shot
setting, i.e. applying only to a single invocation. Now the JAX-WS spec
doesn't make this explicit, but reading between the lines of say the
following FAQ entry[1] on jax-ws.dev.java.net suggests that's the
intention.
So does anyone a) know why ClientImpl.invoke() calls
EndpointInfo.setAddress() and/or b) object to me removing this?
When looking into this I noticed a couple of other bizzarro aspects of
the ENDPOINT_ADDRESS mechanism as currently implemented in CXF.
1. the JaxWsClientProxy ctor sets
BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real EndpointInfo
address in the request context. But since the request context is cleared
between requests, this setting is only available (to logical handlers
etc.) for the *first* invocation on the proxy. Surely that's wrong, or?
2. any overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
JAX-WS LogicalHandler is ignored. This is because the
ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
handlers have been traversed. Surely that's wrong too, or?
I'm open to correction from anyone with more insight into the intent of
the JAX-WS expert group.
Cheers,
Eoghan
[1] https://jax-ws.dev.java.net/faq/index.html
"Q. How can I change the Web Service address dynamically for a request ?
((BindingProvider)proxy).getRequestContext().put(BindingProvider.ENDPOIN
T_ADDRESS_PROPERTY, "...");"
Re: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/30/07, Glynn, Eoghan <eo...@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
RE: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> Sent: 30 March 2007 15:38
> To: cxf-dev@incubator.apache.org
> Subject: RE: Why does ClientImpl.invoke() override the
> EndpointInfo address?
>
>
>
> > -----Original Message-----
> > From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> > Sent: 30 March 2007 14:31
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Why does ClientImpl.invoke() override the EndpointInfo
> > address?
> >
> > Glynn, Eoghan wrote:
> >
> > >Folks,
> > >
> > >Does anyone know why ClientImpl.invoke() overrides the
> EndpointInfo
> > >address with the Message.ENDPOINT_ADDRESS property?
> > >
> > >This has the effect of making permanent any application-level
> > >overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY. By
> > >permanent, I mean applying to all subsequent invocations on
> > this proxy,
> > >not just the current one.
> > >
> > >This doesn't seem correct to me, as I'd expect it to be a one-shot
> > >setting, i.e. applying only to a single invocation. Now the
> > JAX-WS spec
> > >doesn't make this explicit, but reading between the lines
> of say the
> > >following FAQ entry[1] on jax-ws.dev.java.net suggests that's the
> > >intention.
> > >
> > >So does anyone a) know why ClientImpl.invoke() calls
> > >EndpointInfo.setAddress() and/or b) object to me removing this?
> > >
> > >
> > Hi Eoghan,
> >
> > I'm not sure of the impact of removing the call to
> > EndpointInfo.setAddress would be on the HTTPConduit:
> > In its constructor, it initialises a URL with
> > EndpointInfo.getAddress().
> > But from what I can see, this initialisation can be deferred, as in
> > any case during send, the HTTPConduit calls into setupURL(), which
> > overwrites this url with a possibly message specific one (so the
> > conduit's behavior w.r.t message specific properties should
> actually
> > be correct).
>
>
> Yep, the HTTPConduit.send() does the right thing in terms of
> respecting the Message.ENDPOINT_ADDRESS override.
>
> And you're right, the setupURL() method could be a bit
> tighter in the sense of re-using the URL created upfront in
> the HTTPConduit ctor, in the case where there's no overriding
> via the Message.ENDPOINT_ADDRESS/PATH_INFO/QUERY_STRING props.
>
> However, the fragility in the current scenario I think may be
> around the ClientImpl.getConduit().
>
> Say the override of the Message.ENDPOINT_ADDRESS is intended
> to change a
> *completely* bogus endpoint definition, e.g. <soap:address
> location="FOO"> , to something sane like
> "http://localhost...". This is the scenario in the jaxws
> ClientServerTest I mentioned.
>
> 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.
>
> Of course, ClientImpl.getConduit() could take cognizance of
> the Message.ENDPOINT_ADDRESS override itself,
Sorry, ignore that idea, doing the Message.ENDPOINT_ADDRESS override in
ClientImpl.getConduit() would also be broken (i.e. have the unhappy
side-effect of being permanent for that proxy).
> 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(BindingProvide
> r.ENDPOINT
> _ADDRESS_PROPERTY, "...")
>
> Which is I guess another reason for doing just-in-time
> Conduit retrieval, but that's a whole separate discussion :)
>
>
> > EndpointInfo.getAddress() is also used by the policy
> interceptors - to
> > match a domain expression in a PolicyAttachment against the current
> > endpoint.
> > <wsp:PolicyAttachment>
> > <wsp:AppliesTo>
> > <wsa:EndpointReference>
> >
> > <wsa:Address>http://localhost:9020/SoapContext/GreeterPort</ws
> > a:Address>
> > </wsa:EndpointReference>
> > </wsp:AppliesTo>
> > <wsp:Policy>....</wsp:Policy>
> > </wsp:PolicyAttachment>
> > Basically, EndpointInfo is used as key to cache effective
> policies. We
> > could change this to a key that is composed of EndpointInfo AND the
> > address.
>
>
> Yep, that seems sensible to me.
>
> If the application overrides the target endpoint, then I'd
> guess they'd also expect the policies to be picked up from
> the overridden endpoint.
>
> But the crucial question is ... at what point in the chain
> does the policy magic kick in?
>
> If its too early in the chain (e.g. before the JAX-WS
> LogcialHandlers have been traversed), then we'd still be
> ignoring any endpoint override that occurs in an application handler.
>
> Cheers,
> Eoghan
>
> > Andrea.
> >
> > >When looking into this I noticed a couple of other bizzarro
> > aspects of
> > >the ENDPOINT_ADDRESS mechanism as currently implemented in CXF.
> > >
> > >1. the JaxWsClientProxy ctor sets
> > >BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real EndpointInfo
> > >address in the request context. But since the request context is
> > >cleared between requests, this setting is only available
> (to logical
> > >handlers
> > >etc.) for the *first* invocation on the proxy. Surely that's
> > wrong, or?
> > >
> > >2. any overriding of the
> > BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
> > >JAX-WS LogicalHandler is ignored. This is because the
> > >ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
> > >upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
> > >handlers have been traversed. Surely that's wrong too, or?
> > >
> > >I'm open to correction from anyone with more insight into
> > the intent of
> > >the JAX-WS expert group.
> > >
> > >Cheers,
> > >Eoghan
> > >
> > >
> > >[1] https://jax-ws.dev.java.net/faq/index.html
> > >"Q. How can I change the Web Service address dynamically for
> > a request ?
> > >
> > >((BindingProvider)proxy).getRequestContext().put(BindingProvi
> > der.ENDPOIN
> > >T_ADDRESS_PROPERTY, "...");"
> > >
> > >
> >
> >
>
RE: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> Sent: 30 March 2007 14:31
> To: cxf-dev@incubator.apache.org
> Subject: Re: Why does ClientImpl.invoke() override the
> EndpointInfo address?
>
> Glynn, Eoghan wrote:
>
> >Folks,
> >
> >Does anyone know why ClientImpl.invoke() overrides the EndpointInfo
> >address with the Message.ENDPOINT_ADDRESS property?
> >
> >This has the effect of making permanent any application-level
> >overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY. By
> >permanent, I mean applying to all subsequent invocations on
> this proxy,
> >not just the current one.
> >
> >This doesn't seem correct to me, as I'd expect it to be a one-shot
> >setting, i.e. applying only to a single invocation. Now the
> JAX-WS spec
> >doesn't make this explicit, but reading between the lines of say the
> >following FAQ entry[1] on jax-ws.dev.java.net suggests that's the
> >intention.
> >
> >So does anyone a) know why ClientImpl.invoke() calls
> >EndpointInfo.setAddress() and/or b) object to me removing this?
> >
> >
> Hi Eoghan,
>
> I'm not sure of the impact of removing the call to
> EndpointInfo.setAddress would be on the HTTPConduit:
> In its constructor, it initialises a URL with
> EndpointInfo.getAddress().
> But from what I can see, this initialisation can be deferred,
> as in any case during send, the HTTPConduit calls into
> setupURL(), which overwrites this url with a possibly message
> specific one (so the conduit's behavior w.r.t message
> specific properties should actually be correct).
Yep, the HTTPConduit.send() does the right thing in terms of respecting
the Message.ENDPOINT_ADDRESS override.
And you're right, the setupURL() method could be a bit tighter in the
sense of re-using the URL created upfront in the HTTPConduit ctor, in
the case where there's no overriding via the
Message.ENDPOINT_ADDRESS/PATH_INFO/QUERY_STRING props.
However, the fragility in the current scenario I think may be around the
ClientImpl.getConduit().
Say the override of the Message.ENDPOINT_ADDRESS is intended to change a
*completely* bogus endpoint definition, e.g. <soap:address
location="FOO"> , to something sane like "http://localhost...". This is
the scenario in the jaxws ClientServerTest I mentioned.
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.
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 :)
> EndpointInfo.getAddress() is also used by the policy
> interceptors - to match a domain expression in a
> PolicyAttachment against the current endpoint.
> <wsp:PolicyAttachment>
> <wsp:AppliesTo>
> <wsa:EndpointReference>
>
> <wsa:Address>http://localhost:9020/SoapContext/GreeterPort</ws
> a:Address>
> </wsa:EndpointReference>
> </wsp:AppliesTo>
> <wsp:Policy>....</wsp:Policy>
> </wsp:PolicyAttachment>
> Basically, EndpointInfo is used as key to cache effective
> policies. We could change this to a key that is composed of
> EndpointInfo AND the address.
Yep, that seems sensible to me.
If the application overrides the target endpoint, then I'd guess they'd
also expect the policies to be picked up from the overridden endpoint.
But the crucial question is ... at what point in the chain does the
policy magic kick in?
If its too early in the chain (e.g. before the JAX-WS LogcialHandlers
have been traversed), then we'd still be ignoring any endpoint override
that occurs in an application handler.
Cheers,
Eoghan
> Andrea.
>
> >When looking into this I noticed a couple of other bizzarro
> aspects of
> >the ENDPOINT_ADDRESS mechanism as currently implemented in CXF.
> >
> >1. the JaxWsClientProxy ctor sets
> >BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real EndpointInfo
> >address in the request context. But since the request context is
> >cleared between requests, this setting is only available (to logical
> >handlers
> >etc.) for the *first* invocation on the proxy. Surely that's
> wrong, or?
> >
> >2. any overriding of the
> BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
> >JAX-WS LogicalHandler is ignored. This is because the
> >ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
> >upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
> >handlers have been traversed. Surely that's wrong too, or?
> >
> >I'm open to correction from anyone with more insight into
> the intent of
> >the JAX-WS expert group.
> >
> >Cheers,
> >Eoghan
> >
> >
> >[1] https://jax-ws.dev.java.net/faq/index.html
> >"Q. How can I change the Web Service address dynamically for
> a request ?
> >
> >((BindingProvider)proxy).getRequestContext().put(BindingProvi
> der.ENDPOIN
> >T_ADDRESS_PROPERTY, "...");"
> >
> >
>
>
Re: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by Andrea Smyth <an...@iona.com>.
Glynn, Eoghan wrote:
>Folks,
>
>Does anyone know why ClientImpl.invoke() overrides the EndpointInfo
>address with the Message.ENDPOINT_ADDRESS property?
>
>This has the effect of making permanent any application-level overriding
>of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY. By permanent, I mean
>applying to all subsequent invocations on this proxy, not just the
>current one.
>
>This doesn't seem correct to me, as I'd expect it to be a one-shot
>setting, i.e. applying only to a single invocation. Now the JAX-WS spec
>doesn't make this explicit, but reading between the lines of say the
>following FAQ entry[1] on jax-ws.dev.java.net suggests that's the
>intention.
>
>So does anyone a) know why ClientImpl.invoke() calls
>EndpointInfo.setAddress() and/or b) object to me removing this?
>
>
Hi Eoghan,
I'm not sure of the impact of removing the call to
EndpointInfo.setAddress would be on the HTTPConduit:
In its constructor, it initialises a URL with EndpointInfo.getAddress().
But from what I can see, this initialisation can be deferred, as in any
case during send, the HTTPConduit calls into setupURL(), which
overwrites this url with a possibly message specific one
(so the conduit's behavior w.r.t message specific properties should
actually be correct).
EndpointInfo.getAddress() is also used by the policy interceptors - to
match a domain expression in a PolicyAttachment against the current
endpoint.
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>http://localhost:9020/SoapContext/GreeterPort</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:Policy>....</wsp:Policy>
</wsp:PolicyAttachment>
Basically, EndpointInfo is used as key to cache effective policies. We
could change this to a key that is composed of EndpointInfo AND the address.
Andrea.
>When looking into this I noticed a couple of other bizzarro aspects of
>the ENDPOINT_ADDRESS mechanism as currently implemented in CXF.
>
>1. the JaxWsClientProxy ctor sets
>BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real EndpointInfo
>address in the request context. But since the request context is cleared
>between requests, this setting is only available (to logical handlers
>etc.) for the *first* invocation on the proxy. Surely that's wrong, or?
>
>2. any overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
>JAX-WS LogicalHandler is ignored. This is because the
>ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
>upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
>handlers have been traversed. Surely that's wrong too, or?
>
>I'm open to correction from anyone with more insight into the intent of
>the JAX-WS expert group.
>
>Cheers,
>Eoghan
>
>
>[1] https://jax-ws.dev.java.net/faq/index.html
>"Q. How can I change the Web Service address dynamically for a request ?
>
>((BindingProvider)proxy).getRequestContext().put(BindingProvider.ENDPOIN
>T_ADDRESS_PROPERTY, "...");"
>
>
RE: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> 2. any overriding of the
> BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
> > JAX-WS LogicalHandler is ignored. This is because the
> > ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
> > upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
> > handlers have been traversed. Surely that's wrong too, or?
>
>
> Would we just want to rerun the interceptor after the logical
> handlers then?
> (I don't really see any other solutions, but thats just me)
Re-run which interceptor?
Or do you mean, re-run the
ContextPropertiesMapping.mapRequestfromJaxws2Cxf() utility after the
logical handlers have been traversed?
Well its not as simple as that unfortunately.
AFAIK, the policy interceptor that dynamically adds to the chain to
reflect the asserted policies is run the SETUP phase. So the policies
have already been applied to chain *before* the JAX-WS logical handler
gets in and overrides the endpoint address.
Say a client-side external policy attachment asserts the Addressing
policy for endpoint A only. The application kicks off an invocation on
endpoint B. So no WS-A interceptors are included in the chain. Then half
way thru' the dispatch, a logical handler overrides the address so as to
effectively reference endpoint A. But the WS-A interceptors can't be
added retrospectively.
Cheers,
Eoghan
> Regards,
> - Dan
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/30/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> Folks,
>
> Does anyone know why ClientImpl.invoke() overrides the EndpointInfo
> address with the Message.ENDPOINT_ADDRESS property?
>
> This has the effect of making permanent any application-level overriding
> of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY. By permanent, I mean
> applying to all subsequent invocations on this proxy, not just the
> current one.
>
> This doesn't seem correct to me, as I'd expect it to be a one-shot
> setting, i.e. applying only to a single invocation. Now the JAX-WS spec
> doesn't make this explicit, but reading between the lines of say the
> following FAQ entry[1] on jax-ws.dev.java.net suggests that's the
> intention.
>
> So does anyone a) know why ClientImpl.invoke() calls
> EndpointInfo.setAddress() and/or b) object to me removing this?
+1 to removing that.
When looking into this I noticed a couple of other bizzarro aspects of
> the ENDPOINT_ADDRESS mechanism as currently implemented in CXF.
>
> 1. the JaxWsClientProxy ctor sets
> BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real EndpointInfo
> address in the request context. But since the request context is cleared
> between requests, this setting is only available (to logical handlers
> etc.) for the *first* invocation on the proxy. Surely that's wrong, or?
Sounds wrong to me.
2. any overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a
> JAX-WS LogicalHandler is ignored. This is because the
> ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only called
> upfront in the JaxWsClientProxy.invoke(), but not after the JAX-WS
> handlers have been traversed. Surely that's wrong too, or?
>
> I'm open to correction from anyone with more insight into the intent of
> the JAX-WS expert group.
Would we just want to rerun the interceptor after the logical handlers then?
(I don't really see any other solutions, but thats just me)
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Why does ClientImpl.invoke() override the EndpointInfo address?
Posted by "Glynn, Eoghan" <eo...@iona.com>.
I should also have explained why I'm thinking this persisting of the
address override beyond a single invocation may have been deliberate.
Its because this (seemingly incorrect) behaviour is asserted by the
jaxws system test in ClientServerTest.testBogusAddress().
/Eoghan
> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> Sent: 30 March 2007 13:53
> To: cxf-dev@incubator.apache.org
> Subject: Why does ClientImpl.invoke() override the
> EndpointInfo address?
>
>
>
> Folks,
>
> Does anyone know why ClientImpl.invoke() overrides the
> EndpointInfo address with the Message.ENDPOINT_ADDRESS property?
>
> This has the effect of making permanent any application-level
> overriding of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY.
> By permanent, I mean applying to all subsequent invocations
> on this proxy, not just the current one.
>
> This doesn't seem correct to me, as I'd expect it to be a
> one-shot setting, i.e. applying only to a single invocation.
> Now the JAX-WS spec doesn't make this explicit, but reading
> between the lines of say the following FAQ entry[1] on
> jax-ws.dev.java.net suggests that's the intention.
>
> So does anyone a) know why ClientImpl.invoke() calls
> EndpointInfo.setAddress() and/or b) object to me removing this?
>
> When looking into this I noticed a couple of other bizzarro
> aspects of the ENDPOINT_ADDRESS mechanism as currently
> implemented in CXF.
>
> 1. the JaxWsClientProxy ctor sets
> BindingProvider.ENDPOINT_ADDRESS_PROPERTY to the real
> EndpointInfo address in the request context. But since the
> request context is cleared between requests, this setting is
> only available (to logical handlers
> etc.) for the *first* invocation on the proxy. Surely that's
> wrong, or?
>
> 2. any overriding of the
> BindingProvider.ENDPOINT_ADDRESS_PROPERTY in a JAX-WS
> LogicalHandler is ignored. This is because the
> ContextPropertiesMapping..mapRequestfromJaxws2Cxf() is only
> called upfront in the JaxWsClientProxy.invoke(), but not
> after the JAX-WS handlers have been traversed. Surely that's
> wrong too, or?
>
> I'm open to correction from anyone with more insight into the
> intent of the JAX-WS expert group.
>
> Cheers,
> Eoghan
>
>
> [1] https://jax-ws.dev.java.net/faq/index.html
> "Q. How can I change the Web Service address dynamically for
> a request ?
>
> ((BindingProvider)proxy).getRequestContext().put(BindingProvid
> er.ENDPOIN
> T_ADDRESS_PROPERTY, "...");"
>