cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Service address in WSDL and EPR
Date Wed, 17 Sep 2008 19:39:23 GMT
On Wednesday 17 September 2008 3:28:13 pm Jarek Gawor wrote:
> Hi,
> I was working in Geronimo on a simple issue where the service endpoint
> url address in WSDL gets cached on the very first request and does not
> get updated. I was looking through similar code in CXF and noticed a
> few things and now I'm wondering how things should work.
> 1) What's the purpose of publishedEndpointUrl property? I see that it
> can be set in EndpointImpl and it is used in WSDLQueryHandler to
> update the service soap:address location. But, a) shouldn't this
> property be also used to update the schema/wsdl imports? and b)
> shouldn't that value also be returned in
> WebServiceContext.getEndpointReference() and/or
> Endpoint.getEndpointReference()?

It's to workaround issues with various proxy servers and load balancers that 
don't properly send a "Host" variable or the proxy is on a different port 
than the real.    In those cases, the updated URL would not properly reflect 
the "public" URL that is really being exposed to the internet.  The 
publishedEndpointUrl kind of allows overriding the serlvet container provided 
information with the real information that the public would know about.

> 2) The service endpoint address in WSDL returned by CXFServlet will be
> updated each time because ServletController.updateDests() updates the
> address property of the endpoint. But doesn't that create a little
> race condition with WebServiceContext.getEndpointReference()? For
> example, if you have 2 concurrent requests one getting the WSDL and
> another one calling WebServiceContext.getEndpointReference()? Maybe
> WebServiceContext.getEndpointReference() should be using the request
> url instead of the endpoint address for the EPR address?

Yes.    There is a known race condition in there.   Another example is two 
clients requesting the same wsdl, but on different ports or hosts (like 
one "localhost" and another  the external host name).     Also, all endpoints 
that share the same wsdl from the cache in wsdl manager also have the same 

There definitely needs to be a "sync" on the endpoint when mucking with this.  
Just haven't had time to really dig into it to figure it all out.

Daniel Kulp

View raw message