`@Size` annotation on `List<String>` causes incorrect openapi spec to be generated.

[caspianb]

Hopefully this is the correct library to handle this issue; I was referred here from springdoc/springdoc-openapi#2337 -- apologies if I got it wrong.

Using a simple DTO can reproduce this issue:

@Data
static class RequestDto {
    @Size(min = 1, max = 5)
    @Schema(description = "List of values.")
    private List<String> values;
}

The @Size validation is only (correctly) applied to the list size. However, the api spec itself is showing this:

Essentially, the API spec is stating that:

1. the list must be between 1 and 5 elements (correct);
2. the length of the string of each element must be between 1 and 5 characters (incorrect)

You can also see that the description is also being duplicated from the array down to the element as well. I am uncertain if this is intentional and or desirable so not sure if that should also be considered a bug as well.

---

Note that the actual runtime validation is only applied to point1 above (correct behavior IMO).
Point2 is not enforced by the validator at runtime even though the generated API spec is indicating that the string should be between 1 and 5 characters in length.

This also just started occurring when we updated springdoc-openapi-starter-webmvc-ui to 2.2.0 (from 2.1.0).

[Mattias-G]

It seems this bug was introduced in version 2.2.13 and still exists in 2.2.15 (currently latest version).

[WannabeSoftwareEngineer]

the problematic part (introduced in #4429)

        if (annotatedType.getCtxAnnotations() != null) {
            strippedCtxAnnotations.addAll(Arrays.stream(
                    annotatedType.getCtxAnnotations()).filter(
                    ass -> !ass.annotationType().getName().startsWith("io.swagger")
            ).collect(Collectors.toList()));
        }

where annotatedType is, in this case, List<String> and when we try to resolve the schema for the value type of this collection, i.e., String, we are passing down the annotations applied to the container also to the value type.

@frantuma any suggestion how we can resolve this regression?

[frantuma]

Thanks for reporting and analyzing this!

It has been addressed in #4500 by excluding also javax.validation annotations from "custom annotation processing".

[caspianb]

Thank you! Quick question based on the PR: will this also work for jakarta.validation? javax.validation is effectively deprecated now I believe?

[frantuma]

yes it will

[WannabeSoftwareEngineer]

Do you know already when will the next release be?

[frantuma]

no fixed ETA but should be next 1-2 days