JAX-RS subresource issue in Quarkus native build

[DeMol-EE]

Describe the bug

General architecture:

@Path("foo")
@RequestScoped
public class FooResource {

  @Path("{id}")
  public BarResource bar(@Context ResourceContext rc) {
        return rc.initResource(CDI.current()
                .select(BarResource.class)
                .get());
  }
}

@Dependent
@Unremovable
@RegisterForReflection
public class BarResource {

  @PathParam("id")
  String id;

  // some CDI @Inject dependencies omitted

  @GET
  public boolean get(@QueryParam("bar") Integer bar) {
    return true;
  }
}

When executing an HTTP GET for /foo/some?bar=5, we get the following exception:

Encountered an issue: org.jboss.resteasy.spi.InternalServerErrorException: RESTEASY003815: Subresource for target class has no qualifying annotations.: ...BarResource.class...
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:157)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:131)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:33)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:429)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:240)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:154)
	at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:321)
	at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:157)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:229)
	at io.quarkus.resteasy.runtime.standalone.RequestDispatcher.service(RequestDispatcher.java:82)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.dispatch(VertxRequestHandler.java:147)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler$1.run(VertxRequestHandler.java:93)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:582)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base@21.0.1/java.lang.Thread.runWith(Thread.java:1596)
	at java.base@21.0.1/java.lang.Thread.run(Thread.java:1583)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:832)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.posix.thread.PosixPlatformThreads.pthreadStartRoutine(PosixPlatformThreads.java:211)

Expected behavior

No exception, or detection of the issue at build time.

Actual behavior

Exception when trying to call endpoint specified in subresource

How to Reproduce?

See reproducer

Output of uname -a or ver

runtime provided by quarkus-micro-image:2.0

Output of java -version

jdk 21 used in the mandrel build image

Mandrel or GraalVM version (if different from Java)

built with quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21, released with quay.io/quarkus/quarkus-micro-image:2.0

Quarkus version or git rev

3.5.2

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

mvn 3.9.5, via mvnw 3.2.0

Additional information

• JAXRS extension: quarkus-resteasy-jackson
• We added @RegisterForReflection after reading this, but to no avail
• Getting subresources and CDI to work never went smoothly, it took some trial-and-error but the shenanigans with ResourceContext work.
• this is a minimal Quarkus app with strictly quarkus extensions as dependencies

[quarkus-bot]

/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel,native-image)

[DeMol-EE]

Another message I’m getting:

...(executor-thread-1) Encountered an issue: java.lang.RuntimeException: RESTEASY003875: Unable to find a constructor that takes a String param or a valueOf() or fromString() method for jakarta.ws.rs.QueryParam("someId") on public boolean ...FooResource.fooMethod(boolean,java.lang.Integer) for basetype: java.lang.Integer

[galderz]

@DeMol-EE Do you have a reproducer?

[DeMol-EE]

@galderz here you go: https://github.com/DeMol-EE/quarkus-reproducer-37148

Working flow (non-native):

1. Run with mvn quarkus:dev
2. Do curl "http://localhost:8080/hello/foo?bar=5"
3. Receive the response "Hello foo 5".

Error flow:

1. Package with docker build -t reproducer-37148 .
2. Run with docker run --rm -p 8080:8080 reproducer-37148
3. Do curl "http://localhost:8080/hello/foo?bar=5"
4. Observe the error.

[DeMol-EE]

I’ve noticed something new. It appears that on each HTTP request, a new instance of BarResource (the subresource) is created (as expected as it’s a @Dependent bean), but it is not being cleaned up after the response is sent. I’ve added the following to both resources:

    @PostConstruct
    public void hi() {
        System.out.println(">" + this.getClass().getSimpleName());
    }

    @PreDestroy
    public void bye() {
        System.out.println("<" + this.getClass().getSimpleName());
    }

and on each request, the following is logged:

>FooResource_Subclass
>BarResource_Subclass
<FooResource_Subclass

implying that BarResource is being retained somewhere. On quitting quarkus (stopping dev mode by hitting q), we can see the @PreDestroy hook of the subresource is being called and the instances are being released.

Perhaps the leak is somehow resulting in an issue in the native compilation but this is a wild guess (I really have very little knowledge in this area).

We found this while investigating a memory leak in our application. This thread has been inspirational, but I don’t understand what is retaining the instances in our case because nothing is @ApplicationScoped. I’m fairly certain it has to do with the programmatic CDI lookup, but I did not expect this. I would have expected that the obtained contextual reference follows the lifecycle of the resource. I’d love to hear @mkouba’s thoughts on this. I’ve updated the reproducer.

Note that we have been able to get around the issue by doing any one of the following:

• use @Inject to inject an instance of the sub resource in the parent resource resolves the issue (the dependent sub resource has its lifecycle bound properly)
• rescope the sub resource as @RequestScoped
• flatten the sub resource (i.e. inlining it into the parent)

There is still a memory leak in our application and I’m starting to lean towards making everything application scoped by default, instead of dependent... but that’s my concern.

[DeMol-EE]

Observation: moving from RESTEasy classic to RESTEasy reactive fixes the native build! However, the @PathParam in the sub resource is not set (it’s always null, even in jvm mode), though that is to be expected according to the spec, as CDI act as creator in our case:

A JAX-RS implementation is only required to set the annotated field and bean property values of instances created by its runtime. Objects returned by sub-resource locators (see Sub Resources) are expected to be initialized by their creator.

It is a little surprising that CDI does not set the fields, but perhaps we'll get that in the (near) future, with JAXRS 4.
The retention of the dependent sub resource is still there though...

[DeMol-EE]

bump @galderz

[michalvavrik]

Observation: moving from RESTEasy classic to RESTEasy reactive fixes the native build! However, the @PathParam in the sub resource is not set (it’s always null, even in jvm mode), though that is to be expected according to the spec, as CDI act as creator in our case:

cc @geoand

[geoand]

Please open a new issue for the RESTEasy Reactive problem

[geoand]

It is a little surprising that CDI does not set the fields, but perhaps we'll get that in the (near) future, with JAXRS 4.
The retention of the dependent sub resource is still there though...

Jakarta REST until recently do not have any OOTB integration with CDI, so this is expected (RESTEasy Reactive however does have this integration built in from day 1).

[DeMol-EE]

@geoand I see, but I'd like to point out that neither implementation sets fields annotated with @PathParam in sub-resources. With RESTEasy classic, injecting ResourceContext and calling initResource (as shown in the original post) did the trick, but this no longer works for RESTEasy Reactive. Am I to understand that with reactive @PathParam fields should be injected? And is that the problem you are referring to when asking to create a new ticket? Or are you referring to the seeming memory leak when doing a programmatic lookup of @Dependent sub-resources?

[geoand]

Am I to understand that with reactive @PathParam fields should be injected? And is that the problem you are referring to when asking to create a new ticket

Right this.

[tanadeau]

@DeMol-EE: I'm seeing the same problem with @PathParam injection for subresources. I couldn't find a new ticket. Did you create one? If not, I was going to alongside a reproducer next week.