The distribution is organized as follows:

    +-- doc             
    |   |
    |   +-- guide            This User's Guide
    |   |
    |   +-- api              The API JavaDoc
    |
    |-- etc                  Example message resources
    |
    +-- lib                  JAR dependencies
    |
    +-- src                  The library source
    |
    +-- test                 The unit test source

The root directory contains the validator-*.jar distribution JARs:

The Bean Validator uses commons-logging (supplied with the distribution) to remain logging implementation-indepenent.

To use Bean Validator in a JEE session bean, first define @Interceptors(com.sadalbari.validator.ejb.ValidatorInterceptor) on session beans whose methods you want to perform validation on.

The EJB integration layer works by recursively validating parameters with the @ValidateParam annotation. You must also ensure that each method on which validation occurs declares com.sadalbari.validator.ejb.ValidationException in its throws clause.

Later versions of Bean Validator will support working via EJB persistence interceptors.

The Bean Validator was actually designed with Seam in mind and has special support for integrating into it.

To use the Bean Validator interceptor on your stateful session bean, simply annotate it with the @Valid annotation. This interceptor is itself annotated with Seam's @Within annotation to force it to run within Seam's own validation and bijection interceptors.

Use the com.sadalbari.validator.seam.core.annotation.ValidateChild annotation to mark injected components for recursive validation. And that's it -- Bean Validator tries to link the messages to Faces components, just like Seam does, and it also mimics Seam's behaviour where the @IfInvalid annotation is concerned (hopefully Seam will provide pluggable validator support to make this a little more elegant.)

The Bean Validator supports adding property validation errors to components with IDs equal to the property name to a Faces Context. This will work in many cases, but what happens when you have two properties nested within embedded or associated objects but with the same name?

The @PrefixBeanName annotation, discussed in ???, solves this problem by allowing you to prefix errors from a particular bean with a custom string and a '.' delimiter.

public class Level1 {

    public Level2 getFirstChild() { }
	
    public Level2 getSecondChild() { }
	
}

public class Level2 {

    public Level3 getLevel3() { }
	
}

public class Level3 {
	
    @Required
    public String getName();
	
}

Now let's say we have following EJB intercepted method that persists Level1 objects:

...
   public void addLevel1(
       @ValidateParam(prefixes={
           @PrefixBeanName(bean="firstChild.level3", prefix="firstChildLevel3"),
           @PrefixBeanName(bean="secondChild.level3", prefix="secondChildLevel3")})
       Level1 level1);
...

That's quite a mouthful, but what it implies is that when you use FacesMessageGenerator to add messages, if the Level3 objects lacked the required name properties, errors would be added to the components with the Client IDs firstChildLevel3.name and secondChildLevel3.name, rather than name and, well, name.

The Seam equivalent is similar -- you simply add a prefixes attribute to the @ValidateChild annotation.