You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Tawfik Lachheb (JIRA)" <ji...@apache.org> on 2007/10/26 18:36:55 UTC
[jira] Created: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
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.
[jira] Commented: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539656 ]
Daniel Kulp commented on CXF-1144:
----------------------------------
The jaxws spec and TCK basically requires that we create separate top level complexTypes for the wrappers. Kind of sucks.
With the latest snapshots, you can configure this in the runtime via spring config:
<jaxws:server address="/jaxwsAndJaxb"
serviceClass="org.apache.cxf.authservice.AuthService">
<jaxws:serviceBean>
<bean class="org.apache.cxf.authservice.AuthServiceImpl" />
</jaxws:serviceBean>
<jaxws:serviceFactory>
<bean class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
<property name="anonymousWrapperTypes" value="true"/>
</bean>
</jaxws:serviceFactory>
</jaxws:server>
The ?wsdl returned from that would use the anonymous complextTypes instead of separate types. This isn't available in the java2wsdl tooling though.
> 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.
[jira] Commented: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Tawfik Lachheb (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Tawfik Lachheb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538143 ]
Tawfik Lachheb commented on CXF-1144:
-------------------------------------
Is it possible to make the method request elements appear the same way they did in xfire? The xfire way worked fine with .NET clients.
> 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.
[jira] Commented: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Tawfik Lachheb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539721 ]
Tawfik Lachheb commented on CXF-1144:
-------------------------------------
I have verified that your fix works with the simple fromtend + aegis. Thanks!
> 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.
[jira] Resolved: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-1144.
------------------------------
Resolution: Fixed
Fix Version/s: 2.0.3
> 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
> Fix For: 2.0.3
>
>
> 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.
[jira] Commented: (CXF-1144) Issue with .NET clients - stub method
parameters wrapped in a parameter class
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538130 ]
Glen Mazza commented on CXF-1144:
---------------------------------
What's the bug?
> 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.