[REQ][Java][Spring] Generate validation for type arguments in containers via mustache template

Is your feature request related to a problem? Please describe.

On our project, we would like to specify individual error messages for each constraint (e.g. @Pattern or @Size). For this, there is already a vendor extension (x-pattern-message) in the BeanValidationCore.mustache template as an example. The problem is that while validation annotations are generated for non-container types, such as String, based on the mustache template, annotations for type arguments in containers are merged with the container type in the generator itself. Therefore, in such a case, we have no chance to provide a unique error message and we receive the default messages given by Jakarta.

Non-container example:

exampleString:
  type: string
  pattern: "^\d{10,50}$"
  x-pattern-message: "invalid example"

@Pattern(regex = "^\\d{10,50}$", message = "invalid example")
public String getExampleString() {
  return exampleString;
}

Container example:

exampleList:
  type: array
  items:
    type: string
    pattern: "^\d{10,50}$"
    x-pattern-message: "invalid example"

public List<@Pattern(regex = "^\\d{10,50}$") String> getExampleList() {
  return exampleList;
}

Describe the solution you'd like

Currently, annotations for type arguments are "hard-coded" (source) and assigned to the dataType along with the container type. It should be split into two separate variables and used in mustache templates that way. I think it would be good if the generator used the BeanValidationCore.mustache template (or a new one) for container types as well as for non-container types. This would provide the opportunity to take control over what we want the generator to do in these cases by customizing the mustache templates.

Note

If no one applies for the task, I will gladly take it on, because we really need this feature (or something similar) on the project :D

Start with AbstractJavaCodegen.java around line 1154 and the BeanValidationCore.mustache template to trace how container type-argument annotations are assembled. Confirm how the existing x-pattern-message extension is applied for non-container types, then determine how the container path can use the template as well. Done means container elements can receive customized validation messages like the provided example.