Feature Schema.RequiredMode.AUTO Should Consider Meta-Annotations

[adase11]

With the changes to @Schema to deprecate the required attribute and replace it with requiredMode in #4286 the auto resolution accounts for annotations directly on the attribute. A nice enhancement would be to also consider any meta-annotations as well. For example:

I have the following custom annotation

@Constraint(validatedBy = {})
@NotNull(message = "must be a valid verification code")
@Pattern(regexp = VERIFICATION_CODE_REGEX, message = "must be a valid verification code")
public @interface ValidVerificationCode {
...
}

It would be nice to have this auto resolved as not null as well by the Schema.RequiredMode.AUTO.

[kzander91]

All meta-annotations should be considered, not just to see if an attribute is required.

@adase11: Does Swagger generate a pattern restriction for you?

I have an annotation like this, but the generated Spec does not contain the regexp constraint.

@Retention(RUNTIME)
@Constraint(validatedBy = {})
@Pattern(regexp = "^[A-Z\\d-]{1,32}/[A-Z\\d-]{4,20}$")
public @interface ValidUsername {
   ...
}

[adase11]

Agreed @kzander91 - I'm observing the same behavior you are.

[frantuma]

Swagger Core is relying (also) on underlying Jackson annotation processing, which supports meta annotations annotated with @JacksonAnnotationsInside.

The above examples would work if updated to:

@Retention(RetentionPolicy.RUNTIME)
@JacksonAnnotationsInside
@Constraint(validatedBy = {})
@NotNull(message = "must be a valid verification code")
@Pattern(regexp = VERIFICATION_CODE_REGEX, message = "must be a valid verification code")
public @interface ValidVerificationCode {
...
}

and

@Retention(RetentionPolicy.RUNTIME)
@JacksonAnnotationsInside
@Constraint(validatedBy = {})
@Pattern(regexp = "^[A-Z\\d-]{1,32}/[A-Z\\d-]{4,20}$")
public @interface ValidUsername {
   ...
}

Closing ticket, please reopen if you're still experiencing issues

[kzander91]

This works, but is pretty unexpected... Adding a Jackson annotation to something that doesn't have anything to do with Jackson (from my application's point of view) is certainly an unsatisfying solution...

This also requires a compile-time dependency on jackson-annotations, which may not be pretty if a the custom annotations are defined in a separate module.