Hi Daniel, Thanks for the response. I added the @RequestWrapper/@ResponseWrapper as recommended, but the outcome is the same: the wrapper's are not being put into the proper namespace :(
Here are the updated Java interfaces: @WebService(targetNamespace="http://com.foo";) public interface FooService { @WebMethod @RequestWrapper(targetNamespace="http://com.foo";) @ResponseWrapper(targetNamespace="http://com.foo";) @WebResult(targetNamespace="http://com.foo";) String myFooMethod(String x); } @WebService(targetNamespace="http://com.bar";) public interface BarService { @WebMethod @RequestWrapper(targetNamespace="http://com.bar";) @ResponseWrapper(targetNamespace="http://com.bar";) @WebResult(targetNamespace="http://com.bar";) String myBarMethod(String x); } Thanks, Al On Thu, Jul 21, 2011 at 3:39 PM, Daniel Kulp <[email protected]> wrote: > > > You may need to also add @RequestWrapper/@ResponseWrapper annotations to > the > methods to define the namespaces used for the generated wrappers. The > @WebResult/@WebParam annotations define them for the elements IN the > request/response wrapper sequences (for example, you see the line: > > <xs:element minOccurs="0" ref="ns2:return"/> > > to refer to the element in a different namespace). The other annotations > would generate the appropriate wrapper elements in their appropriate > namespace. > > Dan > > > > On Thursday, July 21, 2011 10:30:03 AM Algirdas Veitas wrote: > > Hi, > > > > Am hoping someone can give me a hand with a potential issue (or a > > misunderstanding on my part) with java2ws with respect to the target > > namespaces being generated for the operation message types. > > > > Some background: We have a requirement to move roughly 15 web services > from > > "Code-First" to "Contract-First". In addition, we now need to collapse > > these 15 web services into 1 big WSDL (not my choice). To date we have > been > > using java2ws via the cxf-java2ws-plugin (2.3.1) to generate the WSDL for > > each of our services. > > > > Now, to boil this (potential) issue (or misunderstanding) down to a small > > size, let say we have 2 existing Web Services and that we need collapse > into > > 1 WSDL and then move away from Code-First. Here are there definitions: > > > > package com.foo; > > @WebService(targetNamespace="http://com.foo";) > > public interface FooService { > > @WebMethod > > @WebResult(targetNamespace="http://com.foo";) > > String myFooMethod(String x); > > } > > > > package com.bar; > > @WebService(targetNamespace="http://com.bar";) > > public interface BarService { > > @WebMethod > > @WebResult(targetNamespace="http://com.bar";) > > String myBarMethod(String x); > > } > > > > After running java2ws on these 2 services, we see that the > targetNamespace > > for elements and complexTypes "myBarMethod" and "myBarResponse" are " > > http://com.bar";, which is expected (some attributes and other elements > > removed for clarity): > > > > <xs:schema xmlns:tns="http://com.bar"; targetNamespace="http://com.bar"; > > version="1.0"> > > <xs:element name="myBarMethod" type="tns:myBarMethod"/> > > <xs:element name="myBarMethodResponse" type="tns:myBarMethodResponse"/> > > <xs:complexType name="myBarMethod"> > > <xs:sequence> > > <xs:element minOccurs="0" name="arg0" type="xs:string"/> > > </xs:sequence> > > </xs:complexType> > > </xs:schema> > > > > > > Now, our solution to merge all of these services into one WSDL was to > > initially generate the WSDL using java2ws and then migrate our > > infrastructure away from java2ws to start using wsdl2java. The following > > solution seemed to be the most efficient to get us there. We would > > basically create a temporary UberService interface that extended > FooService > > and BarService like so to generate the 1 big WSDL > > > > package com; > > @WebService > > public interface UberService > > extends FooService , BarService { > > } > > > > We then process UberService via java2ws and a UberService.wsdl is > generated > > and all methods from each service are merged into one WSDL, exactly what > we > > wanted. However, we did notice that element/complexType "myBarMethod" , > > "myBarMethodResponse" , "myFooMethod" and "myFooMethodResponse" are now > in > > the "http://com"; namespace instead of the expected http://com.bar and > > http://com.foo namespaces respectively > > > > The 3 WSDL's are attached.... > > > > It seems like java2ws in this situation (processing an interface that > > extends other interfaces annotated with @WebService) is ignoring the > > targetNamespace that is defined for both FooService and BarService. > There > > may be a good reason for doing this (specifications, etc) but am not sure > if > > it is a bug or a feature or PEBKAC :) > > > > Anyone have any thoughts? > > > > Al > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com >
