Understanding the best approach in handling business validations in any web application framework is very important. This is especially true when you are working with Richfaces, Seam, EJB3 and JPA entity classes.
I recently struggled to understand how to handle business validations (validations that involved a db read or calculation) in my Seam 2.0 application.
I finally ended up using @org.jboss.seam.annotations.faces.Validator annotation to handle business validations instead of a custom Hibernate Validator.
Why? It turns out that the following facts hold true when using a custom Hibernate Validator:
1) Hibernate Validator classes are designed to be used with entity classes (not session beans).
2) Hibernate Validator classes can not participate in the Seam lifecycle as a Seam component, thus facilities like bijection are not available.
When I created my custom Hibernate Validator and marked it as a Seam component with @Name(...), the bijection was not working as I saw in the Eclipse debugger. So the custom Hibernate Validator solution with constraint on SFSB property or method will work, as long as you don't need to make that validator class a Seam component (and therefore take advantage of bijection facility).
I tried using the validator attribute on my h:inputText fields which pointed to the @Name("foo") as the custom Seam validator. This works better b/c the bijection facility is available and works.
I was able to validate onblur using <a4j:support> as well as when the form was submitted.
So the bottom line is this:
If you need custom validation that the Hibernate Validator API does not offer in the "out-of-the-box" constraints (e.g. @Email, @NotEmpty, @Min, etc.), then you may create your own custom Validator. Create a Seam Validator if you need a Seam component with bijection in your validator class and when you are validating a non-entity field, or create a Hibernate Validator if you need to validate an entity class field.
See attached for an example Seam validator implementation. In the example, the validation checks to make sure there are no dupes and that all entries in the problem and finding codes fields are available (based on db lookup which is injected as a List in the validator classes).
Chapter 17, Java Persistence with Hibernate, Bauer and King