[BUG] [jaxrs-spec] Migrate the quarkus library from RESTEasy Classic to Quarkus REST and fix file-upload types in server interface #24454

Description

The file upload parameter generated for the server interface is incorrect and uses types that Quarkus REST doesn't support.

Currently, the jaxrx-spec generator supports Quarkus v3 (latest major version), however, Quarkus migrated from RESTEasy Classic (quarkus-resteasy) to Quarkus REST (quarkus-rest) from 2021. This migration introduced a new type to handle file uploads, and the current quarkus library of jaxrs-spec still generates the old types from quarkus-rest-easy.

Current output using removed types

public Response uploadFile(..., @FormParam(value = "file") InputStream _fileInputStream) {

Per the Quarkus REST guide, the supported multipart parameter types are FileUpload, java.nio.file.Path, java.io.File, byte[] and Buffer. InputStream is not among them. The idiomatic binding is:

public Response uploadFile(..., @RestForm(value = "file") FileUpload file) {

FileUpload also exposes the part metadata (fileName(), contentType(), size()), and it is the only one of these types that supports several files sharing one part name via List<FileUpload> — the shape produced by an array of format: binary properties (see #24452).

Why this is more than a type swap

pom.mustache for the quarkus library forks on useJakartaEe:

quarkus-rest and org.jboss.resteasy.reactive.* only exist on Quarkus 3.x, so a migration can only apply to the Jakarta branch. Two of the three quarkus samples do not set useJakartaEe and therefore resolve to Quarkus 1.13.7 (released 2021):

• samples/server/petstore/jaxrs-spec-microprofile-openapi-annotations — 1.13.7
• samples/server/petstore/jaxrs-spec-quarkus-mutiny — 1.13.7
• samples/server/petstore/jaxrs-spec/quarkus-security — 3.0.1

Version support context

Both versions the generator currently targets are long out of support. Per the Quarkus release schedule:

So 3.27 is the oldest LTS still receiving active community support, with 3.27.4.1 as its latest micro. That makes it the most conservative target that is both supported and new enough to provide quarkus-rest (which does not exist before 3.9). The generator's current 3.0.1.Final and 1.13.7.Final are both well past EOL — 1.13.7 dates from 2021.

Questions for maintainers

1. Should the quarkus library move to quarkus-rest under useJakartaEe=true, keeping the javax/1.13.7 path on RESTEasy Classic unchanged?
2. Should the two lagging sample configs be flipped to useJakartaEe=true so they exercise the modern stack, accepting a large javax.* → jakarta.* sample diff?
3. Is the useJakartaEe=false (Quarkus 1.13.7) path still worth supporting at all, given it is four years past EOL?
4. Should the Jakarta path target 3.27 (oldest active LTS, as in the draft PR) or 3.33 (newest LTS, supported until Mar 2027)?

This is a breaking change to generated signatures for existing quarkus users (InputStream _fileInputStream → FileUpload file), so it seems worth agreeing on scope before merging.

I have a draft PR implementing option 1 (Jakarta path only, javax untouched) and am happy to adjust it to whatever scope you prefer.

Related

• [jaxrs-spec][quarkus] Migrate the Jakarta path to Quarkus REST and fix file upload types #24455 — Migration to quarkus-rest and fixes arrays of format: binary
• [java][microprofile] Emit List<File> to upload multiple files when declaring an array of binary forms #24453 — the same array fix for the java/microprofile client

Note

samples/server/petstore/jaxrs-spec-quarkus-mutiny is not listed in .github/workflows/samples-jaxrs.yaml, so it is never compiled by CI. It may be worth adding regardless of the outcome here.

openapi-generator version

master (7.25.0-SNAPSHOT)