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