Quarkus REST abstract resources with @Path requires impl. to be CDI beans while RESTEasy does not

[michalvavrik]

Describe the bug

I have mentioned that abstract class like this:

@Path("/hello")
public abstract class AbstractGreetingResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public abstract String hello();
}

with implementation:

public class GreetingResource extends AbstractGreetingResource {
    @Override
    public String hello() {
        return "Hello from Quarkus REST";
    }
}

requires GreetingResource to have bean defining annotation while RESTEasy does not.

Expected behavior

Thrown exception is pretty straightforward, I suppose it is not necessary to document it in https://quarkus.io/guides/rest-migration. I can also imagine that if there is more than one implementor of the AbstractGreetingResource that wouldn't work.

So this issue may not be a bug but a kind/question. Isn't situation with interface same and it still works? I can replace the AbstractGreetingResource parent with interface like below and the exception is gone:

@Path("/hello")
public interface GreetingResourceInterface {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    String hello();

}

Actual behavior

Exception is thrown during a processing of an HTTP request:

2024-06-30 13:18:28,035 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-1) HTTP Request to /hello failed, error id: 5b7aaffd-ded0-4ea5-9018-8fb59798479a-1: java.lang.IllegalArgumentException: Unable to create class 'org.acme.AbstractGreetingResource'. To fix the problem, make sure this class is a CDI bean.
	at io.quarkus.resteasy.reactive.common.runtime.ArcBeanFactory.createInstance(ArcBeanFactory.java:41)
	at org.jboss.resteasy.reactive.server.handlers.InstanceHandler.handle(InstanceHandler.java:26)
	at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:139)
	at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:147)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:599)
	at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2516)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2495)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1521)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:11)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:11)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.RuntimeException: java.lang.InstantiationException
	at io.quarkus.arc.runtime.BeanContainerImpl$DefaultInstanceFactory.create(BeanContainerImpl.java:107)
	at io.quarkus.resteasy.reactive.common.runtime.ArcBeanFactory.createInstance(ArcBeanFactory.java:27)
	... 11 more
Caused by: java.lang.InstantiationException
	at java.base/jdk.internal.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:48)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at io.quarkus.arc.runtime.BeanContainerImpl$DefaultInstanceFactory.create(BeanContainerImpl.java:99)
	... 12 more

How to Reproduce?

Steps to reproduce the behavior:

1. git clone git@github.com:michalvavrik/abstract-quarkus-rest-repro.git
2. cd app
3. mvn clean test (failure)
4. sed -i "s#<artifactId>quarkus-rest</artifactId>#<artifactId>quarkus-resteasy</artifactId>#g" pom.xml (use RESTEasy)
5. mvn clean test (success)

Output of uname -a or ver

Fedora 38

Output of java -version

OpenJDK 21

Quarkus version or git rev

3.12.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.8

Additional information

No response

[geoand]

I am not sure about this really, but I guess if we do it for the interface, we should do it for abstract classes as well.

[michalvavrik]

I am not sure about this really, but I guess if we do it for the interface, we should do it for abstract classes as well.

I am not sure either. The reason why I care for this is that even when I annotated class that extends abstract parent with @Singleton I still got issue in one of many cases. I thought if you fix this issue, I won't have to continue with debugging why it happens in exactly one situation. It might be something specific to QuarkusUnitTest or I made some mistake. Anyway it's hard to find a reason for me. If this is not getting fixed, I'll try to create a reproducer.

[geoand]

No worries, I'll look into it when I have some time.

[michalvavrik]

Thank you.

[geoand]

🙏🏼