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
