Overview
Helidon supports Bean Validation via its integration with JAX-RS/Jersey. The Jakarta Bean Validation specification defines an API to validate Java beans. Bean Validation is supported in REST resource classes as well as in regular application beans.
If bean validation is required outside JAX-RS/Jersey use cases, it is also available in Helidon. It follows the standard Jakarta Bean Validation specification which defines an API to validate Java beans.
Maven Coordinates
To enable Bean Validation,
add the following dependency to your project’s pom.xml (see
Managing Dependencies).
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-bean-validation</artifactId>
</dependency>For general validation, please add to your pom.xml:
<dependency>
<groupId>io.helidon.microprofile.bean-validation</groupId>
<artifactId>helidon-microprofile-bean-validation</artifactId>
</dependency>API
The specification defines a small set of built-in constraints. Their usage is encouraged both in regular constraint declarations and as composing constraints. Using this set of constraints will enhance portability of your constraints across constraint-consuming frameworks relying on the metadata API (such as client side validation frameworks or database schema generation frameworks).
Built-in annotations are annotated with an empty @Constraint annotation to avoid any dependency between the specification API and a specific implementation. Each Jakarta Bean Validation provider must recognize built-in constraint annotations as valid constraint definitions and provide compliant constraint implementations for each. The built-in constraint validation implementation is having a lower priority than an XML mapping definition. In other words ConstraintValidator implementations for built-in constraints can be overridden by using the XML mapping (see Overriding constraint definitions in XML).
All built-in constraints are in the jakarta.validation.constraints package. Here is the list of constraints and their declaration.
| Annotation | Description |
|---|---|
|
The annotated element must be |
|
The annotated element must not be |
|
The annotated element must be true. Supported types are |
|
The annotated element must be false. Supported types are |
|
The annotated element must be a number whose value must be higher or equal to the specified minimum. Supported types are:
Note that
|
|
The annotated element must be a number whose value must be lower or equal to the specified maximum. Supported types are:
Note that
|
|
The annotated element must be a number whose value must be higher or equal to the specified minimum. Supported types are:
Note that
|
|
The annotated element must be a number whose value must be lower or equal to the specified maximum. Supported types are:
Note that
|
|
The annotated element must be a strictly negative number (i.e. 0 is considered as an invalid value). Supported types are:
|
|
The annotated element must be a negative number or 0. Supported types are:
|
|
The annotated element must be a strictly positive number (i.e. 0 is considered as an invalid value). Supported types are:
|
|
The annotated element must be a positive number or 0. Supported types are:
|
|
The annotated element size must be between the specified boundaries (included).
Supported types are:
*
|
|
The annotated element must be a number within accepted range. Supported types are:
|
|
The annotated element must be an instant, date or time in the past.
Supported types are:
|
|
The annotated element must be an instant, date or time in the past or in the present.
The notion of present is defined relatively to the type on which the constraint is
used. For instance, if the constraint is on a Supported types are:
|
|
The annotated element must be an instant, date or time in the future.
Supported types are:
|
|
The annotated element must be an instant, date or time in the present or in the future.
The notion of present here is defined relatively to the type on which the constraint is
used. For instance, if the constraint is on a Supported types are:
|
|
The annotated
|
|
The annotated element must not be |
|
The annotated element must not be |
|
The string has to be a well-formed email address. Exact semantics of what makes up a valid
email address are left to Jakarta Bean Validation providers. Accepts
|
Configuration
Bean Validation can be configured using META-INF/validation.xml.
For more information about configuring the validator factory in validation.xml, see Hibernate Validator Documentation.
Examples
-
The following example shows a simple resource method annotated with
@POSTwhose parameter must be not null and valid. Validating a parameter in this case implies making sure that any constraint annotations in theGreetingclass are satisfied. The resource method shall never be called if the validation fails, with a 400 (Bad Request) status code returned instead.@Path("helloworld") public class HelloWorld { @POST @Consumes(MediaType.APPLICATION_JSON) public void post(@NotNull @Valid Greeting greeting) { // ... } } -
The following example shows a simple application with one field declared as not null using
@NotNullannotation:public class GreetingHolder { @NotNull private String greeting; }If the bean contains a method parameter annotated with @Valid, and GreetingHolder with null_greeting is passed, then a _ValidationException will be thrown:
@ApplicationScoped public class GreetingProvider { private GreetingHolder greetingHolder; void setGreeting(@Valid GreetingHolder greetingHolder) { this.greetingHolder = greetingHolder; } }Notebeans.xmlis required to identify beans and for bean validation to work properly.
Examples are available in our official GitHub repository.
Additional Information
Helidon uses Hibernate Bean Validator for general bean validation.