[JERSEY-1565] Path associated with PathParam behaves differently on having slash Created: 08/Nov/12  Updated: 31/Mar/14  Resolved: 18/Oct/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9
Fix Version/s: None

Type: Bug Priority: Major
Reporter: padbhat Assignee: Jakub Podlesak
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Attachments: File emp.wadl     Zip Archive REST_AllOps.zip    


Open Empservice.java in the attached application. Focus on @DELETE and @POST. Both have a PathParam associated with them. Observe the @Path annotations on each of these methods.
@DELETE has @Path("/

@POST has @Path("{name}

Note that the difference is the presence of slash in Path annotation corresponding to @POST.

The snippet of WADL generated for these two operations is as below:

<ns0:resource path="/

<ns0:param name="name" style="template" xmlns:ns2="http://www.w3.org/2001/XMLSchema" type="ns2:string"/>
<ns0:method id="deleteEmployee" name="DELETE">
<ns0:representation mediaType="/"/>

<ns0:resource path="{name}

<ns0:param name="name" style="template" xmlns:ns3="http://www.w3.org/2001/XMLSchema" type="ns3:string"/>
<ns0:method id="updateEmployee" name="POST">
<ns0:representation mediaType="application/json"/>

Here, as seen,

{name} and /{name}

are not treated as the same. However, as per the WADL spec, they are to be treated the same.

Comment by Jakub Podlesak [ 18/Oct/13 ]

The most obvious workaround for this is to stick with @Path("


") annotation at both sub-resource methods.
I am ready to re-evaluate if there would be more information provided why the above suggested workaround should not work.

Comment by trentadams [ 31/Mar/14 ]

I've found that the following behave differently as well..



For the above, the parameter is output in the wadl. For the one below, the wadl does not indicate that there is a securityToken path parameter. But, if I have the prefixed slash, an extra slash is there when concatenating the base resource and resource path. We use XSL for creating a test page, so it's important we see that parameter.



Would this likely be the same bug?

Generated at Tue Jun 02 15:07:36 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.