cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Streit <>
Subject Re: Retrieve WSDL over https with authentication
Date Thu, 19 Jan 2012 21:52:48 GMT
Not sure this addresses your specific issue, but if you can "localize" the
WSDL/XSDs files used to generate the client proxy service and interface
(and method wrapper classes, etc)  into a JAR file where they are copied
into the *META-INF/wsdl* location of *that JAR*, then use the -*wsdlLocation
*attribute to specify this at generation time.

We did something like this below in an Ant build.xml that creates the
"client" JAR...  (this project is not using Maven as many do):

    <!-- JAX-WS task definitions for CXF -->
    <target name="cxfWSDLToJava" depends="init, copy-wsdl-local">
        <java classname=""
            <arg value="-wsdlLocation" />
            <arg value="/META-INF/wsdl/${ws.endpointName}.wsdl" />
            <arg value="-d" />
            <arg value="${src}" />
            <arg value="-client" />
            <arg value="-verbose" />
            <arg value="${src}/META-INF/wsdl/${ws.endpointName}.wsdl" />
                <path refid="cxf.classpath" />
                <path refid="project.classpath" />

There was a recent change in the wsdl2java tool based on something I had
reported here:

We have always run our JAX-WS client applications with WSDL and any
imported XSD files *localized* like this  (which means any XSD imports the
WSDL has must also use the relative location),

For this example test project we were using to evaluate CXF, we generated
the WSDL/XSD files first and the <types> section looks like this:

    <schema xmlns="">
        <import namespace=""
        <import namespace=""
        <import namespace=""

The WSDL and the 3 XSDs are all in the same location (locally) in the
/META-INF/wsdl location so they can be found.

Doing this insures the generated artifacts and the files from which they
were generated are in sync.

Running the client program with the JAR in the classpath worked.

We are *not* using *https *so this may still be problematic for you, I
don't know.  Just putting it out there in case it might be of any help as
it pulls the WSDL from the location relative to the packaged JAR file.

There are far more experienced CXF folks out there (ie: Daniel Kulp, Glen
Mazza - who will likely have more/better info.


On Thu, Jan 19, 2012 at 1:48 PM, rouble <> wrote:

> CXF Gurus,
> I can write a web client that can communicates with a secure web
> service using authentication:
> fooWebServiceUrl =
> "<
> ";
> fooWebService_ss = new FooWebService_Service();
> fooWebService_ss.addPort(FooWebService_Service.FooWebServiceImplPort,
>               ,
>                         fooWebServiceUrl);
> fooWebService = fooWebService_ss.getPort(
>                         FooWebService_Service.FooWebServiceImplPort,
>                          FooWebService.class);
> After this I get an http conduit, from fooWebService, and configure
> authentication and tls. However, this above code assumes that the WSDL
> exists on the file system. That is, by default this line:
> fooWebService_ss = new FooWebService_Service();
> will look for the WSDL, where the wsdl2java command found the wsdl.
> What if I want to retrieve the WSDL from the URL as follows:
>  fooWebService_ss = new FooWebService_Service(new URL(fooWebServiceUrl));
> This won't work, as written, because there is no authentication or tls
> configured at the time the WSDL is retrieved.
> How can this be done? Is it even possible?
> tia,
> rouble


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