BeanValidation

Table 9-2 Built-In Bean Validation Constraints

@AssertFalse
boolean isUnsupported;

@AssertTrue
boolean isActive;

@DecimalMax("30.00")
BigDecimal discount;

@DecimalMin("5.00")
BigDecimal discount;

@Digits(integer=6, fraction=2)
BigDecimal price;

@Future
Date eventDate;

@Max(10)
int quantity;

@Min(5)
int quantity;

@NotNull
String username;

@Null
String unusedString;

@Past
Date birthday;

@Pattern(regexp="\\(\\d{3}\\)\\d{3}-\\d{4}")
String phoneNumber;

@Size(min=2, max=240)
String briefMessage;

The Bean Validation API does not only allow to validate single class instances but also complete object graphs. To do so, just annotate a field or property representing a reference to another object with@Valid. If the parent object is validated, all referenced objects annotated with @Valid will be validated as well (as will be their children etc.)

  Constraints groups

On the presentation tier, it may happen that you have to use the same form bean in two different contexts, such as create and update. In both contexts you have different constraints. For example, when creating your profile, the username is mandatory. When updating, it cannot be changed so there's no need to validate it.

Groups and Inheritance

A group can extend another group, and since groups are interfaces a group can extend more than one group. When the validator evaluates a specific group's constraints it also evaluates all of its super groups (interfaces) constraints. So actually a better way to configure the Book bean validation groups would have been as illustrated bellow:

public interface BookLifeCycle extends Default {}

public interface Draft extends BookLifeCycle{}

public interface Printing extends Draft{}

Validating a Bean based on its Life Cycle Phase

A nice pattern, or structure, is when the bean announces its own lifecycle phase - for that reason I added the BookLifeCycle interface, by adding to the bean a reference to its own life cycle phase we can use it to validate the bean:

GroupSequence

To control the order in which groups are validated the @GroupSequence annotation can be used.

@GroupSequence({Default.class, Draft.class, Printing.class})
public interface BookOrderedValidation {}

Multiple Instances of the Same Constraints

we would like a string property to either be in pattern A or B.

@Pattern.List( {@Pattern(regexp="A.*"), @Pattern(regexp="B.*")} )
private String title;

Different Constraint Configurations per Group

Using the inner List annotation one can also apply different constraint configurations for each validation group. 

@Min.List( { @Min(value = 100, groups = Printing.class), @Min(value = 5, groups = Draft.class) })
private int numOfPages;

Custome Bean Validator - Comparing 2 fields on one class

There doesn't seem to be a way to access other values from an object when validating one of its properties. The solution is to put the annotation on the class, then the validator will get the entire object in to validate against, and you can access just the info you need to perform the validation.

PayLoad

an attribute payload that can be used by clients of the Bean Validation API to asign custom payload objects to a constraint. This attribute is not used by the API itself.

public class Severity {
    public static class Info extends ConstraintPayload {};
    public static class Error extends ConstraintPayload {};
}

public class ContactDetails {
    @NotNull(message="Name is mandatory", payload=Severity.Error.class)
    private String name;

    @NotNull(message="Phone number not specified, but not mandatory", payload=Severity.Info.class)
    private String phoneNumber;

    // ...
}

Now a client can after the validation of a   ContactDetails instance access the severity of a constraint using   ConstraintViolation.getConstraintDescriptor().getPayload() and adjust its behaviour depending on the severity.