Bean validation in Java EE

Here we start simple by having only one interesting property: emailAddress which should not be null, and should be a valid email address. Hibernate Validation declares validation constraints using Java annotations, which can be put on entity bean property fields or getter methods, much in the same way that you define your database mappings in JPA.

Hibernate Validation comes with many predefined validation constraint annotations, and provides a way to define your own if you need anything else. To solve our problem we are going to use the @NotNull and @EMail annotation constraints on our emailAddress property which will declare that this property must not be null and must be a valid email address:

Person.java

If we try to persist a Person with a null or invalid email address, the JPA layer will throw an InvalidStateException (because Hibernate Validation enforces validation constraints automatically when saving an entity). This exception will possibly be wrapped by a transaction exception. But these validation constraints are more useful for other reasons:

Here in the view where we edit a Person we instruct Seam to validate each field (the <s:validateAll> tag), and place the validation messages after each invalid field (the afterInvalidField facet). This will use the validation constraints we defined in the Entity to validate the values during the Process Validations JSF phase.

edit.xhtml

As you can see it is quite straightforward.

This is the code which will be invoked on the server when the view described above will be invoked. It uses the personID request parameter (injected by Seam using the @RequestParameter annotation) to load a Person object from the database and outject it in the editedPerson variable using a factory method (initEditedPerson) which will be invoked when editedPerson is null.

Once the editedPerson has been sent to the view for editing, there are two ways out of the view: canceling (calling the cancel() method) or saving (calling save()). Canceling simply does nothing, and saving is as straightforward as instructing the persistence layer (PersonDAO) to save our entity in the database, since it has already been automatically validated.

PersonActionBean.java

JPA actually comes with several constraints declarations such as:

The duplication of the "NOT NULL" database constraint between JPA and Hibernate Validation is not merely unfortunate:

Furthermore, for the same reasons, unicity constraints defined in JPA cannot be localised, generate a different exception, and are not used in Hibernate Validation and Seam. What is worse though is that they cannot be replaced by an equivalent custom Hibernate Validation constraint for several practical reasons (API problems we can overcome), and one more fundamental and implacable reason: unicity can only be checked reliably while committing the transaction. Indeed, because it depends on other values in the database, nothing prevents other concurrent transactions from modifying other values after you’ve checked manually for unicity and before you commit your transaction (aside from locking).

Forgetting the fundamental issue, we’ve attempted to implement our own unicity constraint in Hibernate Validation, for sport mainly, and in order to check if that framework was really capable of providing an alternative to JPA’s unicity constraints.

Let us start simply by adding a single-column unicity constraint to Hibernate Validation on our entity:

Person.java

Here is how the @Unique annotation would be defined:

Unique.java

And here is how we would define the validation class:

UnicityValidator.java

As you can see, we only get the value we are validating (a particular email address), and with only that we simply cannot check for unicity: we need to know the type of object we are validating, and the particular property we are checking for unicity.

There are five ways out of this limitation:

Since we personally dislike the first 3 options, we will discuss the last two:

So we are left with the option of doing both. Extending Hibernate Validation to provide more information about the bean and the annotated property for property-level constraints and extending Seam so that bean-level validation is executed during the Process Validations lifecycle. Any bean-level validation error messages would be displayed globally rather than next to the edited field since they cannot be associated to a particular property.

Our modifications in Hibernate Validation is very straight-forward and backwards-compatible: we define a subclass of Validator called ExtendedValidator which provides us with the appropriate information when validating:

This method is then invoked in ClassValidator when the validator happens to implement ExtendedValidator. This makes sure that all previously-defined validators still work. We then have to overload the Validator.getPotentialInvalidValues method with an extra parameter for the bean instance, which we use in Seam.

In Seam we then still have to invoke bean validation, but this is at odds with the approach during the Process Validations lifecycle, which does not set the bean properties but uses Validator.getPotentialInvalidValues to check for validity without touching the bean instance. Because there is no equivalent potent equivalent to bean-level validation, something deeper has to change. What then? We’re not sure, but we’re still working on the solution.

Additionally, it would be really nice if bean-level validation could specify different error messages for different errors, as well as specify more than one error (not just returning false) and map errors to property names, so that a bean-level validator could do just as much as property-level validators.

When we integrated web services in our application, we decided to go with bean validation all the way, and get rid of all the validation (validation: not permissions) in the web services frontend. We simply attempt to use whatever the client gives us and the validating persistence layer will complain if needed, at which point we can easily access the error message and format it for the web service client. We just had to move the validation from the action beans into the persistence tier.

While this seems like a good idea, our validation is actually more complex than what we abstracted into the entity beans. In other words, we got hit by limitations in Hibernate Validation. This includes what has been described earlier: the lack of bean-level validation in Seam, its limitations in error reporting and property association, and the lack of support for unicity constraints in Hibernate Validation.

We also discovered that we had more fundamental problems with validation: our beans actually have states, in the sense than some properties should be validated differently based on other properties, thus creating a dependency graph. To give you an example, suppose we add SMS integration in our system, and users can now be contacted either by email, SMS, or both, but having neither email nor SMS is invalid. How can we validate this?

Person.java

Clearly with property-level validation there is no way to specify that one of those can be null if and only if the other is not null. We are left with bean-level validation, which has several drawbacks:

Not happy with bean-level validation, we set out to declare that we need conditional validation: validation which is enabled or disabled based on some conditions. Just at the same time, we noticed that there is a JSR under way to standardise Bean Validation: JSR-303, so we set out to look at it and see if it solves our problems.

Validation conditions are then defined in various flavours, depending on the condition they are checking. The most simple example is the @ValidationConditionOnTrue which defines a validation condition on a bean property which evaluates to true:

@ValidationConditionOnTrue

Now that we are familiar with the difference between referencing and defining a validation condition, let us look at more complex validation conditions, such as the @ValidationConditionOnUEL which defines a validation condition based on a Unified Expression Language (UEL) expression. This is very useful for checks on properties located anywhere within the bean, multiple properties, or even sub-properties. With this we can accomplish our minimum requirement of having at least one of the postAddress or emailAddress properties set:

@ValidationConditionOnUEL

Note that since the UEL expression has access to the whole bean, it does not matter really whether the validation condition is placed on a property or on the bean itself. It is simply a matter of style and we prefer to have them located near their source, but naturally, should an UEL expression reference several properties, we would place the validation condition definition on the bean for clarity.

We still have one more type of validation condition to see: a validation condition which depends on the success or failure of other validation. In the previous example, we’ve used null checks in UEL, but we also defined @NotNull validation constraints. We would like to be able to reuse those constraints so say "validation this property iff this property failed to validate, or succeeded in validating". Because Java Annotations are so limited, we must resort to referencing those validation constraints by name, which we then must assign. Let us redefine the previous example with this new validation condition:

@ValidationConditionOnValue

Using this last type of validation condition we can even define some dependency: validation which does not make sense if a required validator already failed. In the complex validation required by postal addresses, we want to validate the country code and the post code. But the post code depends on the street and country code, so in order for its validation to be meaningful, we must make sure that the street and country codes have already been validated:

@ValidationConditionOnValue dependency

Note that this previous example only makes sense if Validator is fixed so as to include the whole bean instance even for property validation, otherwise the @ValidPostCode cannot access the street and countryCode properties.

Also note that while we would like in some cases to actually include the validation condition’s definition in the validation constraints themselves (for instance @NotNull(uel = "otherProperty == null")), it is probably better practice to differentiate condition validation references and definitions so that one definition can be reused in multiple references. Due to the lack of inheritance in annotations, all validation annotations will be required to support two attributes more than the current message attribute: String[] validationConditions : default {} and String name : default "". This is unfortunate, but we don’t see any better alternative.

Sometimes it is not enough to support these conditions, and we would like to condition the validation based on some external event outside the scope of the bean itself. For instance, in JPA — which is where Hibernate Validation is applied right now —, we would often like to validate a bean when it is inserted, updated, or before it is deleted. This would then be based on JPA events such as ON_INSERT, ON_UPDATE, ON_DELETE corresponding to the underlying operation done on the entity bean.

Sometimes we also have expensive validation that we would like to only trigger when its costs has to be paid: when the value being checked has changed. For instance when we want to validate an entire collection of entities, we would like to only validate it when that collection has changed. Or to get back to our previous example of postal address validation, we would want to validate the whole address only if any of its property has changed. This can be seen as an additional event in JPA which we can name ON_CHANGE. The validation framework would then be responsible for checking whether the persisted value differs from the validated value, and trigger the validation only if they differ.

Validation Events

We can see from this previous example that we might need some sort of default validation group which would apply to the whole bean or each validation constraint.

Here is an other illustration:

Validation Events 2

Basically because a validation check (running a validator’s isValid) method should be side-effect-free, we can take the simplistic view that during validation we can run every validator, and once we have determined which ones failed with what error messages, and which ones passed, we then proceed to check whether the failed ones were meaningful. They are meaningful if their validation conditions evaluate to true. They could all be resolved at this phase (including the tricky @ValidationConditionOnValue).

In order to be more efficient though, we should attempt to only run validators whose validation conditions evaluate to true. This is very straightforward in the cases of @ValidationConditionOnTrue, @ValidationConditionOnUEL and @ValidationConditionOnEvent. For @ValidationConditionOnValue, which depends on other validators' success or failure, we can attempt to run the referenced validators lazily, unless we get into a dependency loop (which is valid: look at our previous example of requiring at least one of email or postal addresses), in which case we can start resolving the loop by running validators as described previously, since they are supposed to be without side-effect, and validation failures are only meaningful if they pass the validation condition later on.

Implementing @ValidationConditionOnEvent would required a pluggable validation condition from JPA, which could instruct us of the current operation on the bean (insert, update, delete) that triggered the validation. The ON_CHANGE condition event would simply fetch the value currently persisted and use Java equality to check for any change in the value.