[BUG][Java] Nested <OperationId>Request class collides with request body model, breaking existing methods

Offen
  • Stimmt etwas nicht?
#25,646 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java, openapi
Bereich
backend-api-design, tooling

Rechercherichtung

Read Java/libraries/webclient/single_request_parameter.mustache and inspect the Java WebClient generator tests for useSingleRequestParameter. The issue includes a minimal OpenAPI spec shape, though it has not been run separately; generate a client with that shape and inspect the *Api class. Done means the generated nested request class no longer shadows the body model and positional callers can still pass that model.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Issue: Bug
Bug Report Checklist
  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
Description

With useSingleRequestParameter set to true or static, the Java client generates a nested class named <OperationId>Request inside each *Api class. When a request body model has that same name, the nested class shadows the model inside the *Api class:

  • The existing positional method's body parameter now resolves to the nested class, so existing callers that pass the model no longer compile.
  • The nested class's body field is typed as the nested class itself, so there is no way to send the real body.

Enabling the option is expected to be additive (the positional methods are still generated), but in this case it breaks the existing API.

openapi-generator version

Seen with 7.14.0 and 7.27.0 (Gradle plugin). On master, Java/libraries/webclient/single_request_parameter.mustache uses the same <OperationId>Request naming with no collision handling.

OpenAPI declaration file content or url

Minimal spec showing the shape (an operation updateFoo whose request body model is UpdateFooRequest). The behaviour was observed on a larger spec with the same pattern; this reduced version has not been run separately.

openapi: 3.0.3
info: { title: repro, version: "1" }
paths:
  /foo/{id}:
    patch:
      operationId: updateFoo
      parameters:
        - { name: id, in: path, required: true, schema: { type: string } }
      requestBody:
        required: true
        content:
          application/json:
            schema: { $ref: '#/components/schemas/UpdateFooRequest' }
      responses:
        '200': { description: ok }
components:
  schemas:
    UpdateFooRequest:
      type: object
      properties:
        name: { type: string }
Generation Details

generatorName: java, library: webclient, useSingleRequestParameter: static (same result with true).

Steps to reproduce
  1. Generate a Java webclient client from the spec above with useSingleRequestParameter set to static or true.
  2. Look at the generated *Api class.

Actual: a nested public static class UpdateFooRequest containing private UpdateFooRequest updateFooRequest. The positional updateFoo(String id, UpdateFooRequest updateFooRequest) now resolves to the nested class, so code passing the model UpdateFooRequest fails with incompatible types: <model>.UpdateFooRequest cannot be converted to <Api>.UpdateFooRequest.

Expected: no shadowing, for example by giving the request class a non-colliding name (such as UpdateFooRequestParams) or by using fully qualified model names in signatures when a collision exists.

Related issues/PRs

#19827 (adds the option to WebClient), #20679, #24568. I did not find an existing issue for this collision.

Vorherrschende Sprache
Java
Sterne
26.9k
Forks
7.8k
Ø Merge
2 T. 10 Std.
Gemergte PRs (30 T.)
180

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus OpenAPITools/openapi-generator

Alle Issues in OpenAPITools/openapi-generator

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.