cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Parker (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5948) wadl2java -inheritResourceParams: put parent param first
Date Thu, 21 Aug 2014 17:27:14 GMT

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

Matt Parker commented on CXF-5948:
----------------------------------

Hi Sergey, Alexey,

There is still a problem with this feature, in the 3.0.2-SNAPSHOT as of the time of this comment.
I'm using the small test case attached to CXF-5904 (i'm running 'mvn clean generate-sources
-U' and then looking at Test.java). The 'first' and 'last' options do have an effect, but
both options generate inconsistent orders if the leaf path isn't a template param. Consider
the following wadl, which has three resource path elements (name, id, and foo):

{code}
<application xmlns="http://wadl.dev.java.net/2009/02" xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
	<grammars />
	<resources>
		<resource id="Test" path="/{name}">
			<param name="name" style="template" type="xs:string"/>
			<resource path="{id}">
				<param name="id" style="template" type="xs:string"/>
				<method name="PUT" id="publishConnection" >
					<request>
						<representation mediaType="text/plain" />
					</request>
					<response>
					</response>
				</method>
				<method name="GET" id="getConnection" >
					<response>
						<representation mediaType="text/plain" />
					</response>
				</method>
			   <resource path="foo">
                                      <method name="GET" id="getConnectionFoo" />
			   </resource>
			</resource>
		</resource>
	</resources>
</application>
{code}

- when using just -inheritResourceParams with no options, the generated interface is this
(missing @PathParam("id") in publishConnection, but param order in getConnection and getConnectionFoo
are consistent):
{code}
@Path("/{name}")
public interface Test {

    @PUT
    @Consumes("text/plain")
    @Path("/{id}")
    void publishConnection(@PathParam("name") String name);

    @GET
    @Produces("text/plain")
    @Path("/{id}")
    Response getConnection(@PathParam("name") String name, @PathParam("id") String id);

    @GET
    @Path("/{id}/foo")
    void getConnectionFoo(@PathParam("name") String name, @PathParam("id") String id);

}
{code}

- when using *either* -inheritResourceParams=first *or* -inheritResourceParams=last, the order
does not change, and the path params are inconsistent between getConnection and getConnectionFoo:

{code}
@Path("/{name}")
public interface Test {

    @PUT
    @Consumes("text/plain")
    @Path("/{id}")
    void publishConnection(@PathParam("id") String id, @PathParam("name") String name);

    @GET
    @Produces("text/plain")
    @Path("/{id}")
    Response getConnection(@PathParam("id") String id, @PathParam("name") String name);

    @GET
    @Path("/{id}/foo")
    void getConnectionFoo(@PathParam("name") String name, @PathParam("id") String id);

}
{code}

Are you able to reproduce this?

> wadl2java -inheritResourceParams: put parent param first
> --------------------------------------------------------
>
>                 Key: CXF-5948
>                 URL: https://issues.apache.org/jira/browse/CXF-5948
>             Project: CXF
>          Issue Type: Improvement
>          Components: Tooling
>    Affects Versions: 2.7.13
>            Reporter: Alexey Markevich
>            Assignee: Sergey Beryozkin
>            Priority: Minor
>             Fix For: 2.7.13, 3.0.2, 3.1.0
>
>         Attachments: inheritedParamsFirst.patch
>
>
> For 
> {noformat}
> <resource path="{name}">
> 	<param name="name" style="template" type="xs:string"/>
> 	<resource path="{id}">
> 		<param name="id" style="template" type="xs:string"/>
> {noformat}
> the {noformat}@Path("/{name}/{id}"){noformat}
> Expected method params order is
> {noformat}@PathParam("name") String name, @PathParam("id") String id{noformat}



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

Mime
View raw message