cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <>
Subject Re: Controlloing WSDL location name
Date Tue, 28 Aug 2012 13:12:35 GMT
The algorithm used to determine the URL is as shown in point #2 here:

So you have some adjustment options.  Otherwise, existing clients, if 
they're stub-based (wsdl2java based artifacts) will need regeneration 
with the new WSDL so all the hardcoded URL information that those 
artifacts use will get properly updated.

I'm not sure why your SOAP clients need to obtain the WSDL via such a 
wsdl:import statement, per the JAX-WS spec, the WSDL should be 
obtainable via "...web service endpointURL?wsdl" and clients should be 
building their artifacts (wsdl2java) anyway via an already downloaded 
version of that WSDL that they have locally on their machine.


On 08/27/2012 08:11 PM, purecharger wrote:
> I recently upgraded to CXF 2.6.2 from 2.2, and in doing so I separated a
> single web service interface into two interfaces and also changing the name
> of the top level interface used in the deployment descriptor.
> before:
> interface name = Manager
> after:
> interface name = ManagerWS
> and interface Manager extends ManagerWS
> Here is my jax-ws descriptor:
>   <jaxws:endpoint id="Manager"
>      xmlns:s=""
>      serviceName="s:Manager" name="Manager"
>      implementorClass="com.mycompany.ManagerWS"
>      endpointName="s:Manager"
>      implementor="#Manager"
>      address="/Manager" />
> The problem I have now is that the new class name causes the <wsdl:location
> /> to be different, and existing clients break due to the changed port name:
> <wsdl:import
> location="http://localhost:8080/DEV/ws/services/soap/Manager?wsdl=ManagerWS.wsdl"
> namespace="">
> Is it possible to control the WSDL name of this service so that I can keep
> it as 'Manager', allowing existing clients to work as before?
> Ryan
> --
> View this message in context:
> Sent from the cxf-user mailing list archive at

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