12:45 p.m.
Hey everyone,
Today I stumbled upon an issue in resource matching and I'm not sure if
this is a bug or working as specified (but breaking without warning).
This is the test case:
import java.io.IOException;
import java.util.*;
import javax.ws.rs.*;
import org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer;
public class Testcase {
public static void main(String[] args) throws IOException {
UndertowJaxrsServer server = new UndertowJaxrsServer();
server.deploy(new Application() {
@Override
public Set<Class<?>> getClasses() {
return new HashSet<>(Arrays.asList(A.class, B.class));
}
});
server.start();
}
@Path("/b")
public static class A {
@GET
@Path("{x}")
public Response c(@PathParam("x") int ignored) {
return Response.serverError().build();
}
}
@Path("/")
public static class B {
@GET
@Path("b/{x}/c")
public Response c(@PathParam("x") int ignored) {
return Response.ok("c").build();
}
}
}
Without A.class `curl -v http://localhost:8081/b/1/c` works as expected
(yields "c"). With A.class included this leads to a 404.
I've narrowed this down to this method:
https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
; Apparently, if a *class* resource matches (i.e. A) all other class
resources are completely disregarded, even if the matched class can't
actually handle the request.
Looking at the jax-rs spec at
http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxr...
, section 3.7.2, point 1.f, I'm thinking this may actually be the
intended behaviour, but the terminology is a bit confusing to me.
Is this a bug or a feature? If it's working as intended, would it be
feasible to add a warning when registering such a "dead" resource
method? This is a really subtle issue that was a pain to debug :)
Thanks,
- Jonas Konrad