This sounds similar to a problem I had a little while ago with Tuscany generated WSDLs and namespaces that Raymond fixed. See [1] for the full story. The short story is that a fix was applied to the core-databinding and databinding-jaxb modules in the 1.x branch (r755810) and a package-info class needed to be present in any package containing classes that were being used as arguments or return types of a service using the WS binding. An example of the package-info class can be seen in the test2.zip attached to [2].
[1] http://markmail.org/message/aaq25xqkxcpvfry4 [2] https://issues.apache.org/jira/browse/TUSCANY-2853 -----Original Message----- From: Simon Laws [mailto:[email protected]] Sent: Thursday, May 07, 2009 07:38 To: [email protected] Subject: Re: Wrong generated WSDL On Thu, May 7, 2009 at 3:08 PM, <[email protected]> wrote: > > Hi > > I am developing a SCA application using tuscany. I want to publish one > component like a web service. I have one method "getDeviceList" that returns > a vector of devices (Vector<Device>). But wsdl it is wrong because I check > this with the WSDL editor plugin installed in Eclipse Ganymedes. Because of > this wrong wsdl I can not use WSDLToJava to obtain Java code for a client > application. Anybody can check my WSDL? I don`t know enough of WSDL format. > I hope Tuscany can fix these problems. > > You can see Device class in the photo. > > > Thanks > > Un saludo. > Santiago Miguel Aranda Rojas > Telvent Interactiva > Extension: 35999 Hi Santiago Was the service interface defined using a vanilla set of Java classes? You will note in the generated WSDL that two schema are present in the types section. The first describes all of the types and maps to your Java classes. The second describes the message wrapper types required are we run with doc/lit/wrapped style messages by default. The message wrappers reference the types described in the first schema. for example, <xs:element minOccurs="0" name="return" nillable="true" type="vector"/> Where "vector" is a type described in the first schema. In order to create the association between the schema an import is included in the second schema, <xs:import/> The types, by default, are not described in a namespace. Note also that the import specifies no namespace or location.It is up to the XML parser to locate the types in this situation. You are right though that this causes a validation failure on Eclipse. Not sure that that is a valid validation failure. To try and work round this for now we could look to see if it's possible to force the types into a namespace. I'll have to do some research on this as not sure how this would work when using a collection. Raymond is our expert in this area and may have thoughts. Regards Simon
