Page History

...

A new feature defined by the JPA 2.0 specification is the ability to seamlessly integrate with a JSR-303 bean validation provider. With minimal effort, OpenJPA 2.0 can be coupled with a JSR-303 validation provider to provide runtime data validation. By combining these two technologies, you get a standardized persistence solution with the added ability to perform standardized data java bean validation.

What is Bean Validation?

...

The examples thus far have shown the use of validation constraints on individual attributes. That is sufficient in many cases, but validation logic often needs to consider combinations of attributes when validating an entity. For example, the constraints applied to the Image entity validate that an image type is set (not null), the extension on the image file name are of a supported type, and the data format is correct for the indicated type. But, for example, it will not collectively validate that a file named "img0.gif" is of type GIF and the format of the data is for a valid GIF image. There are several options to provide collective validation. One option is to create subclasses of Image, JPEGImage and GIFImage, with constraints geared for each of these types. Another, less invasive and simpler option is to a type-level constraint. Let's modify our Image class to use a custom type-level constraint. Here is the updated Image entity with the new type-level constraint.

...

Bean validation uses validation groups to determine what and when validation occurs. There are no special interfaces to implement or annotations to apply in order to create a validation group. A validation group is denoted simply by a class definition. However, it is strongly recommended that simple interfaces are used. This is a best practice since it makes validation groups more usable in multiple environments. Whereas, if a class or entity definition were used as a validation group, it may pollute the object model of another application by bringing in domain classes and logic that do no not make sense for the application. By default, if a validation group or multiple groups is not specified on an individual constraint, it will be validated using the javax.validation.groups.Default group. Creating a custom group is as simple as creating a new interface definition.

...

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
        http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
    version="2.0" >
...
</persistence>

Validation Modes

Bean validation provides three modes of operation within the JPA environment: auto, callback, and none. As you may have guessed, none disables bean validation for a particular persistence unit. The auto mode, which is the default, enables bean validation if a validation provider is available within the classpath. When callback mode is specified, a bean validation provider must be available for use by the JPA provider. If not, the JPA provider will throw an exception upon instantiation of a new JPA entity manager factory. While auto mode simplifies deployment, it can lead to problems if validation unexpectedly not taking place due to a configuration problem. It is a good practice to use either specify none or callback mode explicitly in order to get consistent behavior. In addition, if none is specified, OpenJPA will do optimization at startup and will not attempt to perform unexpected validation. Explicitly disabling validation is especially important in a JEE6 environment where the container is mandated to provide a validation provider. Thus, unless specified, a JPA 2.0 app running in a container will have validation enabled. This will add additional processing during lifecycle events. We'll get to lifecycle events shortly.

...

Now that we've gone through validation basics and JPA configuration options, the validation part is a piece of cake. In general, you simply need to handle validation exceptions that may result from various JPA operations. Here are some simple examples for the persist, update, and remove operations. We'll get to more in-depth exception handling in a moment.

...

If one or more constraints fail to validate during a lifecycle event, a ConstraintViolationException is thrown by the JPA provider. The ConstraintViolationException thrown by the JPA provider includes the a set of ConstraintViolations that occurred. Individual constraint violations contain information regarding the constraint, including a message, the root bean (JPA entity), the leaf bean (useful when validating JPA embeddables), the attribute which failed to validate, and the value that caused the failure. Here is a sample exception handling routine:

...

Maven Configuration

If you are a maven user, dependency management is much simpler. Here are the dependencies you'll need in order to use OpenJPA 2.0 and the current (as of this writing) snapshot of Apache Bean Validation.

...