[ 
https://issues.apache.org/jira/browse/CXF-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538185
 ] 

Glen Mazza commented on CXF-1144:
---------------------------------

Well your method signatures would still have to be that way for the *response* 
elements, which can only return one data value/object.  (i.e., DoItResponse 
myDIR = port.someCall(); )  It would be strange to have the request elements 
appear in one form but the response elements be the other.  I wonder if you can 
use XSLT to modify the WSDL in the manner that you would like.

Also, as you can see here[1], sometimes a complex type is used for multiple 
elements, so if the complex type was embedded within the element as you're 
requesting, it would need to be duplicated for each element using that complex 
type.

[1] http://preview.tinyurl.com/2wybsv


> Issue with .NET clients - stub method parameters wrapped in a parameter class
> -----------------------------------------------------------------------------
>
>                 Key: CXF-1144
>                 URL: https://issues.apache.org/jira/browse/CXF-1144
>             Project: CXF
>          Issue Type: Bug
>            Reporter: Tawfik Lachheb
>
> We are trying to upgrade our published services from xfire to cxf.  We are 
> using the simple frontend with aegis.  Before we push the upgrade to 
> production, we need to make sure the upgrade as transparent as possible to 
> our users.  With cxf, we see that the .NET client stubs are different from 
> the ones users are getting now from xfire.  A method that appears as 
> doIt(Thing a, Thing b) for example appears as dotIt(DoItRequest request) 
> where DoItRequest contains the a and b parameters.
> I found out that doing a small change to the wsdl makes .NET generate the 
> stubs the way we want them.  Changing the method request element from this 
> for example:
>   <xsd:element name="findFeaturesByExtent" type="tns:findFeaturesByExtent" /> 
>   <xsd:complexType name="findFeaturesByExtent">
>   <xsd:sequence>
>   <xsd:element minOccurs="0" name="extent" type="tns:Envelope" /> 
>   <xsd:element minOccurs="0" name="spatialQueryOptions" 
> type="tns:SpatialQueryOptions" /> 
>   <xsd:element minOccurs="0" name="token" type="xsd:string" /> 
>   </xsd:sequence>
>   </xsd:complexType>
> to this
> <xsd:element name="findFeaturesByExtent">
> <xsd:complexType name="findFeaturesByExtent">
> <xsd:sequence>
> <xsd:element minOccurs="0" name="extent" type="ns0:Envelope"/>
> <xsd:element minOccurs="0" name="spatialQueryOptions" 
> type="ns0:SpatialQueryOptions"/>
> <xsd:element minOccurs="0" name="token" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> fixes the problem.
> Please let me know if you need any additional info.
> Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to