Quarkus 3.15.1 JAX-RS/REST builds fail with UnsupportedOperationException

[dhoffer]

Describe the bug

We are upgrading a Quarkus 2.16.12 app to 3.15.1. We are also replacing our legacy swagger jars to generate the OpenApi files using the OpenAPI microprofile approach.

One of the differences we found is that if we put @JsonView(Views.Ingest.class) at the method level it only was applied to the GET operations. For POST & PUT operations we had to move the @JsonView(Views.Ingest.class) to the RequestBody entity parameter. Without placing the annotation at the request body parameter it would always use the full entity spec instead of the one defined by @JsonView(Views.Ingest.class).

However now that I have made this change for all of our REST services I get the following error. What is causing this? How can I fix this?

I am not using @CustomSerialization or @CustomDeserialization in my code but Quarkus might be using these at build time.

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:3.15.1:build (quarkus-maven-plugin-build) on project sdl: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR]         [error]: Build step io.quarkus.resteasy.reactive.jackson.deployment.processor.ResteasyReactiveJacksonProcessor#handleJsonAnnotations threw an exception: java.lang.UnsupportedOperationException: The `@CustomSerialization` and `@CustomDeserialization` annotations can only be used in methods or classes.
[ERROR]         at io.quarkus.resteasy.reactive.jackson.deployment.processor.ResteasyReactiveJacksonProcessor.getTargetId(ResteasyReactiveJacksonProcessor.java:631)
[ERROR]         at io.quarkus.resteasy.reactive.jackson.deployment.processor.ResteasyReactiveJacksonProcessor.handleJsonAnnotations(ResteasyReactiveJacksonProcessor.java:268)
[ERROR]         at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
[ERROR]         at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
[ERROR]         at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
[ERROR]         at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR]         at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2516)
[ERROR]         at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2495)
[ERROR]         at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1521)
[ERROR]         at java.base/java.lang.Thread.run(Thread.java:1583)
[ERROR]         at org.jboss.threads.JBossThread.run(JBossThread.java:483)

Thanks,
David

Expected behavior

Build would be successful.

Actual behavior

Generates the build error above.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

java 21.0.4 2024-07-16 LTS

Quarkus version or git rev

No response

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

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)

Additional information

No response

[dhoffer]

This is a blocking issue for us, we can't upgrade to 3.15.x until we find a solution.
I went through all of our POST & PUT endpoints and made them all consistent following this format:

@RequestBody(required = true) @JsonView(Views.Ingest.class) @SdlValid WeatherReport entity
@RequestBody(required = true) @JsonView(Views.Ingest.class) List<@SdlValid WeatherReport> entities

Note @SdlValid is defined as this but these have not changed so I don't think its relevant.
@InterceptorBinding
@target({ElementType.TYPE_USE, ElementType.PARAMETER, ElementType.TYPE})
@retention(RetentionPolicy.RUNTIME)
@TypeQualifier
public @interface SdlValid {
}

The bug started to occur after adding the @JsonView(Views.Ingest.class) annotation to the second half of the endpoints. The annotation worked fine for the first half then just stopped working and failing the build as above.

[dhoffer]

I have a little more data to report. When it fails I noticed that the entity being created/edited doesn't actually have any of the Views.Ingest fields so I thought maybe Quarkus is refusing to use a view that has no fields, but I changed the REST method to use a different view that the entities does use and it still fails, so that's not the cause.

Note our views use inheritance so Ingest also contains Abridged which the entity does have. In any case Quarkus should just use the specified view.

Here is our View structure:

`public class Views {
public Views() {
}

public static class Abridged {
    public Abridged() {
    }
}

public static class Ingest extends Abridged {
    public Ingest() {
    }
}

public static class Full extends Ingest {
    public Full() {
    }
}

public static class Max extends Full {
    public Max() {
    }
}

`

Also Quarkus should have better logging output so that it reports why its failing.

Currently I'm still blocked on this.

[dhoffer]

Also just to be clear I saw some discussion on this feature, my understanding this is supported by Quarkus OpenAPI microprofile via smallrye/smallrye-open-api#1209 correct? It works most of the time but not always.

[geoand]

Is this something that #43849 would address?

[quarkus-bot]

/cc @FroMage (rest), @stuartwdouglas (rest)

[dhoffer]

@geoand How would I pull the changes from #43849 to test this? What publicly available Maven version is this in?

[geoand]

@geoand How would I pull the changes from #43849 to test this

You would have to build main.

What publicly available Maven version is this in?

It will be available with 3.16

[gsmet]

One of the differences we found is that if we put @JSONVIEW(Views.Ingest.class) at the method level it only was applied to the GET operations. For POST & PUT operations we had to move the @JSONVIEW(Views.Ingest.class) to the RequestBody entity parameter. Without placing the annotation at the request body parameter it would always use the full entity spec instead of the one defined by @JSONVIEW(Views.Ingest.class).

Just to clarify, it's a difference with how OpenAPI operates or it's a difference at the REST level?

Did you change the REST layer you are using while upgrading (RESTEasy Classic vs Quarkus REST maybe?).

[dhoffer]

@gsmet It was mainly a difference in how OpenAPI operates. For request body's it is ignoring @JSONVIEW if applied on the method. Moving to the request body normally works but not always, when it doesn't work we get the build error.

Also yes we also are now using Quarkus REST not resteasy.

Regarding building main so I can test this new update, that is very challenging I get a build errors at some point. I have tried commenting out failing modules like Gradle but it is not generating the quarkus-universe-bom which our code needs to build.

[dhoffer]

@gsmet Because I was having trouble building Main I pointed to your 999-SNAPSHOT that I understand you build daily and the bug is fixed. However if I'm reading your PR date and the latest snapshot date correctly it seems your PR was after the latest 999-SNAPSHOT which appears to have the fix??

So my next question is how quickly can we get this fix in either 3.15.2 (ideal) or 3.16.0? However if it was fixed post 3.15.1 release and before your PR how would we know what the fix was?

However I did do a partial local build before I just switched to your 999-SNAPSHOT so it's possible that I did successfully build the code that has your PR.

We did a test building on a different system pointed at your 999-SNAPSHOT repo and its not fixed. We will test on that same system tomorrow with the next snapshot and it should confirm that your changes are what fixed this. I'd like to get it in 3.15.2 quickly if possible.

[geoand]

There are multiple ways to build the project from main, I do:

mvn -T 1C -DskipDocs -DskipTests -DskipITs -Dinvoker.skip -DskipExtensionValidation -Dskip.gradle.tests -Dskip.gradle.build -Dtruststore.skip clean install -Prelocations

Then in a project that uses Quarkus you can use version 999-SNAPSHOT but you also have to use quarkus-bom as the artifact id of the BOM.

[dhoffer]

@gsmet That is good build info.

We have confirmed your PR fixes this issue and it's a blocker for us. We are wanting to check into our build pipeline the Quarkus update currently on 3.15.1. But need your fix first. We prefer 3.15.x as it's a LTS version but we could go to 3.16 if we have to. How soon could we get 3.15.2 or 3.16?

[geoand]

The schedule for 3.16 can be found here. For 3.15, it's still being worked out.