Possibly Wildfly JAX-RS URL-Matching Error
scrublet Aug 26, 2014 7:52 PMI've seen a couple cases where a JAX-RS application that works on JBoss AS7 fails to work properly on Wildfly due to client requests reaching the "wrong" method. I put "wrong" in quotes, as I'm assuming that my understanding of what is and isn't acceptable in URL design is correct. Here's an example where I'm seeing this behavior:
@Path("/rootResource")
public class MyResource {
@GET
public MyResourceList getAll() {}
@GET
@Path("{id}") MyResource get(@PathParam("id") int id) {}
@GET
@Path("{id}/meta") ResourceMetadata getMeta(@PathParam("id") int id) {}
// THIS IS THE ONE INCORRECTLY REACHED
@PUT
@Path("{id}") void updateResource(@PathParam("id") int id) {}
@POST
@Path("{id}") void resubmitOldResourceAsNew(@PathParam("id") int id) {}
@PUT
@Path("{id}/enable") void enableResource(@PathParam("id") int id) {}
@PUT
@Path("{id}/disable") void disableResource(@PathParam("id") int id) {}
// THIS IS THE ONE I WANT
@PUT
@Path("disable") void disableAllResources() {}
@DELETE
@Path("{id}") void deleteResource(@PathParam("id") int id) {}
}
Now, if I call /rootResource/disable, i should expect to hit disableAllResources. However, it instead reaches updateResource and tries to process the string "disable" as an int (which then fails). Obviously I can reconstruct the URLs (and for a number of reasons that may wind up happening anyways). But that doesn't change the fact that I believe this URL structure to be totally valid, and that it works fine on JBoss AS7.
Another reason I'm bringing this up is that I had a similar problem with <security-constrant> and <web-resource-collection> in web.xml, where requests were getting allowed through because a URL was being incorrectly mapped to a broader, less-detailed <web-resource-collection>. Both of these cases suggest to me that a possible change in RESTEasy is incorrectly matching URLs too early. Unless I'm misunderstanding a fundamental concept here?