You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "clint dovholuk (JIRA)" <ji...@apache.org> on 2014/07/16 18:08:08 UTC

[jira] [Commented] (CXF-5694) Parameters from WADL in alphabetic order

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

clint dovholuk commented on CXF-5694:
-------------------------------------

Sorry for being absent for so long on this... I've not been able to reproduce it myself so I suppose we should close the bug.  What was happening was that the WADL generator most definitely produced a WADL with the parameters 'out of order'.  I searched my im history and I found the exchange where we simply had renamed the parameter inside the java class and emitted the WADL, which we then consumed into a client (all with the same cxf version).

Prior to renaming the "assetId" field the CLIENT code generated:
@DELETE
    @Produces({"application/xml", "application/json" })
    @Path("/id/{id}/assets/id/{assetId}")
    ExecutionResult removeFromGroup(@PathParam("assetId") String assetId, @PathParam("id") String id);

We then renamed "assetId" to "zassetId", redeployed the server (so we can autogenerate the WADL), and consumed the new WADL and the client code looked like this:
DELETE
    @Produces({"application/xml", "application/json" })
    @Path("/id/{id}/assets/id/{zassetId}")
    ExecutionResult removeFromGroup(@PathParam("id") String id, @PathParam("zassetId") String zassetId);
    
Notice that the "assetId" and "zassetId" are now ordinally transposed.

Anyway - we've worked around it - I can't replicate it. :)

> Parameters from WADL in alphabetic order
> ----------------------------------------
>
>                 Key: CXF-5694
>                 URL: https://issues.apache.org/jira/browse/CXF-5694
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.7.10
>         Environment: linux (fedora 20) and windows 7, java 7 u51
>            Reporter: clint dovholuk
>            Assignee: Sergey Beryozkin
>            Priority: Minor
>
> We have a wadl that we export from cxf 2.7.10 and we turn around and consume the wadl we produce to provide a client jar (which also uses cxf 2.7.10)
> The snippet of wadl we have is here:
>     <resource path="/id/{id}/a/id/{aId}">
>       <param name="id" style="template" type="xs:string" />
>       <param name="aId" style="template" type="xs:string" />
>       <method name="DELETE" id="remove">
>         <request />
>         <response>
>           <representation mediaType="application/xml" element="prefix1:SomeClassToReturn" />
>           <representation mediaType="application/json" />
>         </response>
>       </method>
>     </resource>
> However this generates client code where the "id" and "aId" are out of order like this:
>     @DELETE
>     @Produces({"application/xml", "application/json" })
>     @Path("/id/{id}/a/id/{aId}")
>     SomeClassToReturn remove(@PathParam("aId") String aId, @PathParam("id") String id);
> For kicks we renamed "aId" to "zId" and low and behold we now get (notice the parameter zId at the end now):
>     SomeClassToReturn remove(@PathParam("id") String id, @PathParam("zId") String zId);
> I also found this nabble post as well (though this is for wsdl vs wadl) http://cxf.547215.n5.nabble.com/Ordering-of-wsdl-method-parameters-changed-for-java-first-services-td5736502.html it seems to be indicating the same issue but I didn't see it come to conclusion and I couldn't find any more threads.
> I have filed this bug per Sergey's request



--
This message was sent by Atlassian JIRA
(v6.2#6252)