[BUG] [JAVA] Missing importing @Valid cause compilation issue on client creation

[valerioponte]

Bug Report Checklist

• [v] Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• [v] Have you tested with the latest master to confirm the issue still exists?
• [v] Have you searched for related issues/PRs?
• [v] What's the actual output vs expected output?
  • Actual output: Compilation issue - cannot find symbol [ERROR] symbol: class Valid
  • Expected output: Valid API client code
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

When the query parameter type is declare in a different yaml file but imported as reference and when the type is Array of Enum, it was notice that the client generation produces a not compiling java code.
In the client code, the method argument matching the query parameter is now annotated with @Valid (this was introduced in the openapi version 7.2.0) however the class does not import the annotation resulting in a "cannot find symbol" compilation issue.

openapi-generator version

The version 7.2.0 introduced this issue.

OpenAPI declaration file content or url

Content of first.yaml file

...
paths:
  /resource:
    get:
      parameters:
        - in: query
          name: queryParamListOfEnum
          required: false
          schema:
            type: array
            items:
              $ref: './second.yaml#/components/schemas/QueryParamListOfEnum'
      responses:
        '200':
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Resource'
...

Content of second.yaml file

...
components:
  schemas:    
    QueryParamListOfEnum:
      type: string
      enum:
        - "ABC"
        - "DEF"
...

Generation Details

openapi-generator-maven-plugin

configuration:

<useJakartaEe>true</useJakartaEe>
<library>webclient</library>
<useTags>true</useTags>
<dateLibrary>java8</dateLibrary>
<hideGenerationTimestamp>true</hideGenerationTimestamp>
<apiPackage>${api.package}.client</apiPackage>
<modelPackage>${api.package}.client.models</modelPackage>

Suggest a fix

Include the missing "import jakarta.validation.Valid;" import in the generated client class.

[wing328]

can you please file a PR with the suggested fix?

[arburk]

I also experienced this issue. But it is not valid for all generated files. The import for jakarta.validation.Valid; was missing in one file only while other generated files contained this import.

[wsdng]

The same issue applies to using patterns on the strings in an array parameter, e.g.:

     parameters:
       - name: foos
         in: query
         required: true
         schema:
           type: array
           items:
             type: string
             pattern: ^[A-Z]{1}[A-Z0-9 ]{1,4}$

The generated Code includes a @Pattern annotation but no import.
Note that I've been using config options useSpringBoot3 and useJakartaEe. I am using gradle and Java 17.

[zsait-clearstreet]

Seeing this same issue with 7.3.0 -- missing @Valid import - is anyone working on a fix for this? We also have useBeanValidation set to true, and looking at the code this should import the Valid class, but doesn't?

[rod-dvla]

Issue appears to be limited to the generated DefaultApi class, for both resttemplate and webclient (have encountered it with at least these types of generated client).
See this issue with 7.2.0 and 7.3.0, but no @Valid annotation generated in DefaultApi class on earlier versions so no impact at compile time.

It looks as if parameters surfaced via the lines below can include the @Valid annotation when the operation takes an array of items with attributes that have a format (possibly pattern), and useBeanValidation is true:

webclient

resttemplate

DIfficult to follow the flow of execution though, so I may be incorrect.

[philipdzierzon]

I found the same Problem when upgrading from 7.0.1 to versions >= 7.2.0.

Generator:

<generatorName>java</generatorName>
<library>webclient</library>

I am using the configOptions

<useBeanValidation>true</useBeanValidation>
<performBeanValidation>true</performBeanValidation>
<useJakartaEe>true</useJakartaEe>

It breaks when generating path or query parameters with constraints for apis.
Here no validations are generated in my api class. (required is handled in the code just fine)

paths:
  /my-api/{myParam}:
    get:
      operationId: getStuff
      description: "description"
      parameters:
        - in: path
          name: myParam
          required: true
          schema:
            type: string
            maxLength: 50
            minLength: 5
      responses:
        204:
          description: "Description"

Starting from version 7.2.0 this snippet breaks because validations are generated for the array parameter but the import is missing:

paths:
  /my-api/{myParam}:
    get:
      operationId: getStuff
      description: "description"
      parameters:
        - in: path
          name: myParam
          required: true
          schema:
            type: array
            items:
              type: string
              maxLength: 50
              minLength: 5
      responses:
        204:
          description: "Description"

Generated code 7.1.0 array parameter:

private ResponseSpec getStuffRequestCreation(List<String> myParam) throws WebClientResponseException { ... }

Generated code 7.2.0 array parameter:

private ResponseSpec getStuffRequestCreation(List<@Size(min = 5, max = 50)String> myParam) throws WebClientResponseException { ... }

Generated code 7.1.0 and 7.2.0 string parameter:

private ResponseSpec getStuffRequestCreation(String myParam) throws WebClientResponseException { ... }

My expectation would be that constraints are generated when defined in my api specification and the import is added properly.
Currently constraints are just ignored for api parameters in version <= 7.1.0.

Please tell me if I am configuring something wrong here or if this is an actual bug.

[johannwriesnig]

any updates on this ?

[philipdzierzon]

I just found #18332
It should be the fix for this issue.