XFire

Response message in WSDL generated by XFire Service structurally different from WSDL fed into WsGen Ant Task

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1.1
  • Fix Version/s: 1.1.2
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP Professional SP2
    Sun Java JDK 1.5.0_07
    Tomcat 5.5.17
  • Number of attachments :
    4

Description

I generated a service from an existing WSDL using the WsGen Ant task.
I then looked at the generated WSDL returned by http://localhost/MyService?wsdl.

The Response Message of the generated WSDL is structurally different from the original WSDL fed into WsGen.

My original WSDL had the following specification for the response message:
<xsd:schema targetNamespace="http://ws.wendys.com/AppRelease/"
elementFormDefault="unqualified"
attributeFormDefault="unqualified">
<xsd:complexType name="AppReleaseType">
<xsd:sequence>
<xsd:element type="xsd:string" name="applicationId" minOccurs="1" />
<xsd:element type="xsd:string" name="applicationName" minOccurs="1" />
<xsd:element type="xsd:date" name="availabilityStart" minOccurs="1" />
<xsd:element type="xsd:date" name="availabilityStop" minOccurs="0" />
<xsd:element type="xsd:string" name="releaseId" minOccurs="1" />
<xsd:element type="xsd:string" name="releaseName" minOccurs="1" />
<xsd:element type="xsd:string" name="releaseURL" minOccurs="1" />
<xsd:element type="xsd:string" name="releaseText" minOccurs="1" />
<xsd:element type="xsd:string" name="releaseDesc" minOccurs="0" />
<xsd:element type="xsd:nonNegativeInteger" name="releaseDispOrder" minOccurs="1" />
</xsd:sequence>
</xsd:complexType>

<xsd:element name="getAppReleasesResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element type="acre:AppReleaseType" name="AppRelease" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
.
.
.
<wsdl:message name="getAppReleasesResponseMessage">
<wsdl:part element="acre:getAppReleasesResponse" name="garResponse" />
</wsdl:message>

In the generated WSDL an extra element, ArrayOfAppRelease, was created and the structure of the response message was changed. The generated WSDL had the following specification for the returned message (reformatted to better fit the page and to remove extra xsd:schema groups that don't add anything to the final WSDL):

<xsd:schema targetNamespace="http://apprelease.ws.wendys.com"
elementFormDefault="qualified"
attributeFormDefault="qualified">
<xsd:complexType name="GetAppReleasesType">
<xsd:sequence>
<xsd:element name="appType" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="endPoint" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="language" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="siteNum" type="xsd:int" minOccurs="0" />

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetAppReleasesResponse">
<xsd:sequence>
<xsd:element name="appRelease" type="ns2:ArrayOfAppReleaseType" minOccurs="0" nillable="true" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ArrayOfAppReleaseType">
<xsd:sequence>

<xsd:element name="AppReleaseType"
type="ns2:AppReleaseType"
nillable="true"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AppReleaseType">
<xsd:sequence>
<xsd:element name="applicationId" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="applicationName" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="availabilityStart" type="xsd:dateTime" minOccurs="0" nillable="true" />
<xsd:element name="availabilityStop" type="xsd:dateTime" minOccurs="0" nillable="true" />
<xsd:element name="releaseDesc" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="releaseDispOrder" type="xsd:integer" minOccurs="0" nillable="true" />
<xsd:element name="releaseId" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="releaseName" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="releaseText" type="xsd:string" minOccurs="0" nillable="true" />
<xsd:element name="releaseURL" type="xsd:string" minOccurs="0" nillable="true" />
</xsd:sequence>
</xsd:complexType>

<xsd:element name="getAppReleasesRequest" type="ns2:GetAppReleasesType" />
<xsd:element name="getAppReleasesResponse" type="ns2:GetAppReleasesResponse" />
</xsd:schema>
.
.
.
<wsdl:message name="getAppReleasesResponse">
<wsdl:part element="ns1:getAppReleasesResponse" name="getAppReleasesResponse" />
</wsdl:message>

Note the extra "appRelease" element in the generated Response Message that does not exist in my original WSDL.

I've attached my original WSDL and the generated WSDL for comparison purposes.

  1. XML File
    AppRelease_generated.wsdl
    21/Jun/06 4:14 PM
    6 kB
    Mike McAngus
  2. XML File
    AppRelease.wsdl
    21/Jun/06 4:25 PM
    13 kB
    Mike McAngus
  3. XML File
    AppRelease.wsdl
    21/Jun/06 4:14 PM
    5 kB
    Mike McAngus
  4. XML File
    services.xml
    22/Jun/06 12:00 PM
    0.7 kB
    Mike McAngus

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike McAngus added a comment -

This 3rd attachment is the real original WSDL.

The 1st attachment was a working copy I had created to do some comparisons. Among other things, I had removed documentation from the working copy.

Show
Mike McAngus added a comment - This 3rd attachment is the real original WSDL. The 1st attachment was a working copy I had created to do some comparisons. Among other things, I had removed documentation from the working copy.
Hide
Permalink
Dan Diephouse added a comment -

How are you configuring your service. I think the problem here might be that you're not using the JaxbServiceFactory. It looks like xfire is generating the wsdl instead of using the provided one.

I think at the very least we have bad documentation here and need to fix it. Might potentially be a bug in JaxbServiceFactory too.

Show
Dan Diephouse added a comment - How are you configuring your service. I think the problem here might be that you're not using the JaxbServiceFactory. It looks like xfire is generating the wsdl instead of using the provided one. I think at the very least we have bad documentation here and need to fix it. Might potentially be a bug in JaxbServiceFactory too.
Hide
Permalink
Dan Diephouse added a comment -

I just added some notes on using the generated server classes down at the bottom of this page:

http://xfire.codehaus.org/Client+and+Server+Stub+Generation+from+WSDL

FYI - you can edit this page by clicking Edit on the bottom right. Or if you have feedback I will try to integrate it/improve it. Thanks.

Show
Dan Diephouse added a comment - I just added some notes on using the generated server classes down at the bottom of this page: http://xfire.codehaus.org/Client+and+Server+Stub+Generation+from+WSDL FYI - you can edit this page by clicking Edit on the bottom right. Or if you have feedback I will try to integrate it/improve it. Thanks.
Hide
Permalink
Mike McAngus added a comment -

Dan,

I will try to answer your questions.

How are you configuring your service.

I'm not sure of the question.
The WsGen invocation of my Ant build is:
monspaced
<wsgen outputDirectory="$

{src.dir}

"
wsdl="$

{wsdl.file}

"
package="$

{service.package.root}

"
binding="jaxb"
/>
monspaced
Notice that I am explicitly invoking the JAXB binding.

I think the problem here might be that you're not using the JaxbServiceFactory.

I certainly see no references to the JaxbSereviceFactory in the generated source.

It looks like xfire is generating the wsdl instead of using the provided one.

Correct. When I tried to point to my WSDL in the @WebService.wsdlLocation or the wsdlURL in the services.xml, there were problems (JIRA XFIRE-481 and XFIRE-482).

Show
Mike McAngus added a comment - Dan, I will try to answer your questions. How are you configuring your service. I'm not sure of the question. The WsGen invocation of my Ant build is: monspaced <wsgen outputDirectory="$ {src.dir} " wsdl="$ {wsdl.file} " package="$ {service.package.root} " binding="jaxb" /> monspaced Notice that I am explicitly invoking the JAXB binding. I think the problem here might be that you're not using the JaxbServiceFactory. I certainly see no references to the JaxbSereviceFactory in the generated source. It looks like xfire is generating the wsdl instead of using the provided one. Correct. When I tried to point to my WSDL in the @WebService.wsdlLocation or the wsdlURL in the services.xml, there were problems (JIRA XFIRE-481 and XFIRE-482 ).
Hide
Permalink
Mike McAngus added a comment -

Since JIRA XFIRE-486, XFIRE-487 and XFIRE-488 are marked as duplicates of this, and since this is described as a potential configuration issue, are there any configuration files that you would like me to attach to this JIRA?

Show
Mike McAngus added a comment - Since JIRA XFIRE-486 , XFIRE-487 and XFIRE-488 are marked as duplicates of this, and since this is described as a potential configuration issue, are there any configuration files that you would like me to attach to this JIRA?
Hide
Permalink
Dan Diephouse added a comment -

Can you attach your services.xml file?

Show
Dan Diephouse added a comment - Can you attach your services.xml file?
Hide
Permalink
Mike McAngus added a comment -

Here is my services.xml

Show
Mike McAngus added a comment - Here is my services.xml
Hide
Permalink
Dan Diephouse added a comment -

Try this:

<beans xmlns="http://xfire.codehaus.org/config/1.0">
<service>
<serviceClass>com.wendys.ws.acre.AppReleaseImpl</serviceClass>
<serviceFactory>org.codehaus.xfire.jaxb2.JaxbServiceFactory</serviceFactory>
</service>
</beans>

Show
Dan Diephouse added a comment - Try this: <beans xmlns="http://xfire.codehaus.org/config/1.0"> <service> <serviceClass>com.wendys.ws.acre.AppReleaseImpl</serviceClass> <serviceFactory>org.codehaus.xfire.jaxb2.JaxbServiceFactory</serviceFactory> </service> </beans>
Hide
Permalink
Mike McAngus added a comment -

I applied this change, and now the WSDL returned by the Web Service is no longer structurally different from the WSDL that I fed into the WsGen Ant task.

Note, I had set <serviceFactory>jsr181</serviceFactory> because I wanted the Annotations in the generated source to be parsed. I got this idea from the Service.xml section of the User Guide (http://xfire.codehaus.org/services.xml+Reference).

The WSDL returned is now closer to my original WSDL, and th issue documented in this JIRA does not appear if the serviceFactory element is "org.codehaus.xfire.jaxb2.JaxbServiceFactory". Also, the issues in JIRA XFIRE-486 and XFIRE-488 do not occur with the new serviceFactory. However, I will be reopening JIRA XFIRE-487 (WSDL returned by Service created with WsGen does not preserve element types specified in the original WSDL) because this serviceFactory change does not fix that issue.

Setting serviceFactory to org.codehaus.xfire.jaxb2.JaxbServiceFactory should definitely be identified as a strongly recommended option. There is already a recommendation for setting the serviceFactory to org.codehaus.xfire.xmlbeans.XmlBeansServiceFactory if the developer wants to use XmlBeans. I may investigate have to investigate how the generated WSDL looks when the XMLBeansServiceFactory is used.

I would also recommend supplying simple identifiers for the JaxbServiceFactory and the XmlBeansServiceFactory (similar to the jsr181 and commons-attributes identifiers already supplied) since these two are likely the most highly recommended serviceFactory settings .

The disadvantages of choosing the jsr181 or commons-attributes should probably be documented.

Finally, I would recommend leaving this JIRA open as a Bug because that service factory still needs work to ensure that the WSDL it returns is logically the same as the WSDL fed into WsGen.

Show
Mike McAngus added a comment - I applied this change, and now the WSDL returned by the Web Service is no longer structurally different from the WSDL that I fed into the WsGen Ant task. Note, I had set <serviceFactory>jsr181</serviceFactory> because I wanted the Annotations in the generated source to be parsed. I got this idea from the Service.xml section of the User Guide ( http://xfire.codehaus.org/services.xml+Reference ). The WSDL returned is now closer to my original WSDL, and th issue documented in this JIRA does not appear if the serviceFactory element is "org.codehaus.xfire.jaxb2.JaxbServiceFactory". Also, the issues in JIRA XFIRE-486 and XFIRE-488 do not occur with the new serviceFactory. However, I will be reopening JIRA XFIRE-487 (WSDL returned by Service created with WsGen does not preserve element types specified in the original WSDL) because this serviceFactory change does not fix that issue. Setting serviceFactory to org.codehaus.xfire.jaxb2.JaxbServiceFactory should definitely be identified as a strongly recommended option. There is already a recommendation for setting the serviceFactory to org.codehaus.xfire.xmlbeans.XmlBeansServiceFactory if the developer wants to use XmlBeans. I may investigate have to investigate how the generated WSDL looks when the XMLBeansServiceFactory is used. I would also recommend supplying simple identifiers for the JaxbServiceFactory and the XmlBeansServiceFactory (similar to the jsr181 and commons-attributes identifiers already supplied) since these two are likely the most highly recommended serviceFactory settings . The disadvantages of choosing the jsr181 or commons-attributes should probably be documented. Finally, I would recommend leaving this JIRA open as a Bug because that service factory still needs work to ensure that the WSDL it returns is logically the same as the WSDL fed into WsGen.
Hide
Permalink
Dan Diephouse added a comment -

I created a related issue XFIRE-492 where we weren't writing the wsdlLocation attribute when generating service stubs. This is being done now and you should no longer have to worry about setting the wsdl on the service manually. You'll just need to make sure that you're using the JaxbServiceFactory (now documented).

Show
Dan Diephouse added a comment - I created a related issue XFIRE-492 where we weren't writing the wsdlLocation attribute when generating service stubs. This is being done now and you should no longer have to worry about setting the wsdl on the service manually. You'll just need to make sure that you're using the JaxbServiceFactory (now documented).

People

  • Assignee:
    Dan Diephouse
    Reporter:
    Mike McAngus
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: