Helidon Declarative Validation

[tomas-langer]

Resolves #10735

validation/tests/validation/src/test/java/io/helidon/validation/tests/validation/ValidationTest.java
and
validation/tests/validation/src/test/java/io/helidon/validation/tests/validation/ValidatorTest.java
for usage (not really examples, but what I am testing right now)

Declarative Validation

Validation provides capabilities to validate types and method parameters/return values.
Both features require code-generation.

Type validation code-generation of type validators is triggered by the presence of the @Validation.Validated annotation on a type.

Method validation code-generation of interceptors is triggered by the presence of an annotation "meta-annotated"
with @Validation.Constraint on a method, its parameter, or type arguments of its parameters or return type.
In addition the Check.Valid annotation also triggers code-generation, and can be used to validate against a type validator
mentioned above.

Declaration

Annotations:

• Most annotations from io.helidon.validation.Validation class to trigger validation using an interceptor (all meta-annotated with @Validation.Constraint)
• @Validation.Validated - on a type to generate type validator for a type

Configuration

There is currently no configuration for validation.

Implementation

Each constraint has a dedicated validator provider service, with (default-weight - 30) weight.
The providers are annotated with a named annotation that matches the constraint annotation.

This allows our users to override the implementation using their custom services.

The validation process works as follows:

1. an interceptor is generated for any method that has constraint annotations or valid annotation
2. the interceptor obtains all constraint validation instances and type validators needed to validate a call
3. the interceptor validates the call and throws a ValidationException if validation fails

The type validation works as follows:

1. a type validator is generated for any type that has a @Validation.Validated annotation
2. the type validator obtains all constraint validation instances and type validators needed to validate an instance
3. the type validator validates the type and returns response with possible constraint violations

Important types:

• Validation - a container class for validation annotations
• ValidationException - throws when validation fails in an interceptor
• Validator - programmatic API to validate instances and their properties (only for validated types), can be obtained from service registry
• ConstraintValidatorProvider - service registry service that validates a single constraint annotation type
• ConstraintValidator - created for each annotated element using the type of the element and the constraint annotation
• validators package contains built-in constraint validator providers

Supported concepts:

• any service method annotated with a constraint annotation will be intercepted and validated
• any service method that has parameters with at least one constraint annotation will be intercepted and validated
• for identification of "what to validate", @Validation.Valid is a constraint annotation
• annotations on type arguments of method parameters and method return type are supported, as long as they are on
  Optional, Map, Collection - i.e. List<@Validation.String.NotBlank String> will trigger an interceptor and will be validated
• types annotated with @Validation.Validated will be validated when used in a method or constructor that uses @Validation.Valid on the typed parameter
• same rules as for generation of interceptors apply for type validation: constraints are honored, including getters,
  fields, and type arguments
• a user may create a "compound annotation" - an annotation that has one or more constraint annotations, these will be honored as
  if the element was directly annotated with the constraints
• a user may create a custom constraint annotation (annotation meta-annotated with @Validation.Constraint), such annotations
  may also be meta-annotated with additional constraints; a custom constraint annotation requires a custom validator provider

[Verdent]

I think this is a mistake. You wanted the character at the index 0, right?

[Verdent]

Also, if you add the check for the 4tch character to be upper case as I wrote before, this check would be redundant :-)

[tomas-langer]

This is not redundant, nor is it a mistake - this is for cases such as getADSL - we want to keep all capital...

[tomas-langer]

Examples of generated files:

• ValidatedType__Validated - for a validated record
• ValidatedService__ValidationInterceptor_1 - for an intercepted method that has bot constraints and a validated type

ValidatedType__Validated.java
ValidatedService__ValidationInterceptor_1.java