Adding localName to the RequestWrapper/ResponseWrapper took care of it, for both cases.
Thanks! On Thu, Jul 21, 2011 at 4:45 PM, Daniel Kulp <[email protected]> wrote: > > Can you add localName attributes to those? > > @RequestWrapper(localName="myBarMethod", > targetNamespace="http://com.bar";) > > @ResponseWrapper(localName="myBarMethodResponse" > targetNamespace="http://com.bar";) > > And seeing if that helps. If so, try removing them and then adding the > name > attribute to the @WebMethod. > > Looking at the code, I think it needs to have one of those defined, but > I'd > like to verify that. > > Dan > > > > On Thursday, July 21, 2011 4:41:03 PM Algirdas Veitas wrote: > > Hi Daniel, > > > > In doing a bit more experimentation, it looks like the "issue" manifests > > itself even if you are not extending an interface. The following service > > interface, results in the same issue: > > > > package com; > > @WebService > > public interface UberService > > { > > @WebMethod > > @RequestWrapper(targetNamespace="http://com.bar";) > > @ResponseWrapper(targetNamespace="http://com.bar";) > > String myBarMethod(String x); > > } > > > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:tns=" > > http://com/"; elementFormDefault="unqualified" targetNamespace=" > http://com/"; > > 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:complexType name="myBarMethodResponse"> > > <xs:sequence> > > <xs:element minOccurs="0" name="return" type="xs:string"/> > > </xs:sequence> > > </xs:complexType> > > </xs:schema> > > > > Thanks, > > Al > > > > On Thu, Jul 21, 2011 at 3:59 PM, Algirdas Veitas <[email protected]> > wrote: > > > 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 > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com >
