cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tawfik Lachheb (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-1144) Issue with .NET clients - stub method parameters wrapped in a parameter class
Date Tue, 30 Oct 2007 17:26:50 GMT

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

Tawfik Lachheb commented on CXF-1144:
-------------------------------------

I agree but the response elements being that way does not look as bad as for the request elements.
 Methods never return multiple objects so we are not wrapping multiple objects into one for
responses.  For requests, the methods take multiple parameters but we wrap them into one.
 Inthe .NET client stub we get a lost of methods all taking one wrapper object as a parameter.

Regarding the complex type repetition, I agree we should not have it but could request/response
elements be an exception as opposed to elements representing the object model?  In our case
some services don't have the same parameter combination more than once and othes might have
a combination repeated once or twice at the most.  Increasing the size a little would not
hurt us as we are more interested in the performance of the actual calls to the web service.

> 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.


Mime
View raw message