fabric8io / kubernetes-client

Java client for Kubernetes & OpenShift
http://fabric8.io
Apache License 2.0
3.41k stars 1.46k forks source link

CRD Generator: Cannot specify `@Pattern` annotation on type parameter #6282

Closed adriansuarez closed 1 month ago

adriansuarez commented 2 months ago

Is your enhancement related to a problem? Please describe

Consider the following field in a CRD class:

    @JsonPropertyDescription("A list of names matching the pattern `[A-Za-z][A-Za-z0-9_]*`")
    @JsonProperty
    public List<String> names;

What I would like to be able to add the @io.fabric8.generator.annotation.Pattern annotation so that the Kubernetes API server can validate that the elements of the array match the pattern.

Adding the annotation to the field itself causes the following JSONSchema to be created, which is not what I want:

              names:
                description: A list of names matching the pattern `[A-Za-z][A-Za-z0-9_]*`
                items:
                  type: string
                type: array
                pattern: [A-Za-z][A-Za-z0-9_]*

Describe the solution you'd like

I'd like to declare the validation constraint as follows:

    @JsonPropertyDescription("A list of names")
    @JsonProperty
    public List<@Pattern("[A-Za-z][A-Za-z0-9_]*") String> names;

And have that generate the following JSONSchema:

              names:
                description: A list of names`
                items:
                  type: string
                  pattern: [A-Za-z][A-Za-z0-9_]*
                type: array

This can be achieved by changing the @Target on @Pattern to include ElementType.TYPE_USE, and detecting the presence of the annotation on the type parameters in the declaration to include the pattern constraint.

Describe alternatives you've considered

I've tried various ways to "trick" Fabric8 into letting me put the pattern constraint in the correct place, and nothing has worked.

I tried creating a wrapper class for the string that I can attach the annotation to:

@JsonSerialize(as = String.class)
public class Name {

  private final String value;

  @JsonCreator
  public Name(String value) {
    this.value = value;
  }

  @Pattern("[A-Za-z][A-Za-z0-9_]*")
  @JsonValue
  public String getValue() {
    return value;
  }
}

Unfortunately, the CRD generator does not detect that this class is supposed to be serialized as a string.

The other alternative would be to just have a normal wrapper object that I can attach the annotation to, but that would create gratuitous nesting of properties that I do not want.

Additional context

No response

shawkins commented 2 months ago

This can be achieved by changing the @Target on @Pattern to include ElementType.TYPE_USE, and detecting the presence of the annotation on the type parameters in the declaration to include the pattern constraint.

That seems to be relatively unsupported in Jackson v2 - https://groups.google.com/g/jackson-user/c/f7ZTj-0PFDQ and indeed with the annotation modified, I don't see the annotation in the type information provided to the JSONSchema when poking around in the debugger. There would need to be additional introspection, potentially based upon some hacks like the collectValidationRules method.

Unfortunately, the CRD generator does not detect that this class is supposed to be serialized as a string.

The v2 CRD generator will produce string for the following:

  @Pattern("[A-Za-z][A-Za-z0-9_]*")
  public class Name {

    private final String value;

    @JsonCreator
    public Name(String value) {
      this.value = value;
    }

    @JsonValue
    public String getValue() {
      return value;
    }
  }

  public List<Name> names;

However the Pattern is still not associated because it is not seen by jackson as being associated with the parent field.

If the beanProperty is a collection, and the collection type is string, but the collection class is not java.lang.String we can use:

beanProperty.getType().getContentType().getRawClass().getAnnotation(Pattern.class) to find the nested annotation with this convention. However I agree it's not ideal to have this type of workaround.