On 30/09/2010, at 11:47 PM, Ashwin Karpe wrote: > The answer is yes. Check out the address attribute in the <cxf:endpoint/> > bean.
I'll assume you're referring to the cxfEndpoint element in the http://camel.apache.org/schema/cxf namespace. In which case, I don't believe that works for us. To give you an example of our setup: [client] -> (internet) -> [load balancer] -(1..n)-> [cxf endpoint] where, for examples sake: load balancer: services.example.com (12.34.56.78 - just an example IP address) cxf endpoint: private1.example.com (10.0.0.1) If we set the address attribute to "http://10.0.0.1/service";, the WSDL is populated with <soap:address location="http://10.0.0.1/service"/>, which is inaccessible from the public internet. If we set the address attribute to "http://services.example.com/services";, then Jetty tries to bind to 12.34.56.78, which fails because it doesn't exist on this host. We can get it to do this by setting an entry in /etc/hosts to associate the hostname with the local IP address, though this still doesn't work for us, as our load balancer terminates an SSL connection on the public interface and proxies an unencrypted connection to the CXF endpoint, so the WSDL gets populated with <soap:address location="http://services.example.com/services"/> when we really need it to be <soap:address location="https://services.example.com/services"/>. Furthermore, we will likely need to make use of the OSGi or Servlet transports for CXF, in which case you don't specify the hostname at all in the address attribute, as it is handled by the OSGi HTTP service or servlet container respectively. Once again, we can probably get the web container to pass on the correct external hostname to CXF to set in the WSDL, though we are still unable to specify the transport is HTTPS rather than HTTP. Ideally, the listening address should be separately configurable from the published address in the WSDL. I hope I'm overcomplicating this and missing something obvious here. Regards, Scott Christopher
