Consider a resource method inherited from a package-private superclass:

abstract class PrivateAbstractResourceClass {
    @GET
    public String get() {
        return "test";
          }

}

@Path("root")
public class TestInheritResourceMethodFromPrivateClass extends PrivateAbstractResourceClass { }

The resource method declared in the superclass will be hidden by a bridge method in the resource class (https://bugs.openjdk.org/browse/JDK-6342411). Thus, as any other synthetic method, it won't be considered for registration as resource method by RESTEasy (https://github.com/resteasy/resteasy/blob/81ea5563a4d6e544f666c86cadab3c73a65e30ae/resteasy-core-spi/src/main/java/org/jboss/resteasy/spi/metadata/ResourceBuilder.java#L758)

Expectation: The resource method is registered and works as expected, i.e. the respective requests are handled by the application containing the resource class.

Of course, making the superclass public is a viable work-around. It is, however, not obvious and stronger encapsulation might be desirable.