0 Replies Latest reply on Aug 26, 2014 7:52 PM by Bradley Snyder

    Possibly Wildfly JAX-RS URL-Matching Error

    Bradley Snyder Newbie

      I'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?