+1 on Steve's comment. Does a client need to have access to the actual WSDL at run-time?
And on a related note, is there a way for a client to specify a different endpoint URI at runtime? The current API allows you to pass in a URL to a WSDL file, but what if I just want to use the WSDL I built off of, but want to point all requests at a test server (or just change the port so I can use TCPMon)? All of the other major frameworks make this pretty easy. Maybe it exists in CXF but is undocumented? -Chris -----Original Message----- From: Steven E. Harris [mailto:[EMAIL PROTECTED] Sent: Wed 5/2/2007 4:33 PM To: cxf-user@incubator.apache.org Subject: Why does a JAX-WS client use the WSDL at run time? I'm trying to understand a big difference in how a Web Service client works in JAX-WS/CXF versus AXIS2. In AXIS2, the WSDL2Java process reads a WSDL document and creates a lot of code to create, transport, and consume messages as directed by the WSDL. After this WSDL2Java process, the WSDL document is no longer required; it has essentially been compiled into a set of Java operations that obey the WSDL's specifications. In JAX-WS, the WSDL2Java process also creates code, annotated with details from the motivating WSDL document. I had assumed that these annotations are used at compile time to generate much of the extra code we see generated by the AXIS2 WSDL2Java process. Instead, I find that the generated Service type wants to read a WSDL file in its constructor (following the call chain along to org.apache.cxf.wsdl11.WSDLServiceFactory.create() called on by org.apache.cxf.jaxwsServiceImpl.initializePorts()). Why does the client need to read the WSDL file at run time? Don't the annotations and method signatures provide enough information to lock in the basic operations it must perform? Is there some way to avoid needing to use the WSDL file at run time? -- Steven E. Harris
