JSF2.0 BeanValidation

[Dominik Müller]

Hi together,

plan to edit my application an replace the default jsf validation implementation with a beanvalidation.
Read some articles and tutotials, all look very easy of course , so i re-implement one of my jsf-validatiors as BeanValidator

ValidatorInterface

    
@Constraint(validatedBy = TimeValidator.class)
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ValidTime
{
  String message() default "{valid.time.message}";

  Class<?>[] groups() default {};

  Class<? extends Payload>[] payload() default {};

}

Implementation of course:

    
public class TimeValidator implements ConstraintValidator<ValidTime, MyTime>
{

  public void initialize(ValidTime constraint)
  {

  }

  @Override
  public boolean isValid(MyTime myTime, ConstraintValidatorContext ctx)
  {
      ...
      return false;
 }

Usage in my (hibernate) entity bean

    
@ValidTime
@Entity
@Access(AccessType.FIELD)
public class ProjectTime
{.....

Now the Problem.
I exeptected that the validation takes place the first time when jsf recives the formular commit and update the data model (at the same time the "normal" jsf validator makes his work),
but that seems a misunderstanding. The validator only becomes checked when hibernate try to persist the entity and at this position i get only a stacktrace because jsf doesn't seems to recognize
the "ConstraintViolationException" when it gets thrown by the backend.

Some ideas what i am doing/understanding wrong?

Thanks for helping
Dom

[Tim Holloway]

It actually makes more sense to validate at commit time. It's probably less overhead than looking at each "set" invocation, and any validations that are enforced by schema constraints might not be detectable before then.

You can, of course, validate before updating the model. And JSF validators may be of some service as well. The exact degree of co-operation between different validators is in flux at the moment, so YMMV depending on the JSF implementation and JEE server you're using.

ORM services tend to prefer unchecked exceptions. So for best results, the business logic should surround your commit with a try/catch block and translate the validation exception to a FacesException or (and this is usually better) it should report an error. For example:

/**
 * Persist myRecord.
 * @param myRecord The record to write
 * @return <code>true</code> if the write succeeded.
 */
private boolean writeStuff(MyRecord myRecord) {
    try {
        dao.save(myRecord);
        return true;
   } catch (ValidationException vex) {
        // JSFUtils is my convenience class to keep JSF code out of the beans.
        JSFUtils.addErrorMessage("Invalid data: " + vex.getMessage();
        return false;
   }
}

[Dominik Müller]

Hi (after long time) again,

after some searching i found the problem with BeanValidation + JSF.
JSF does not support global class validation (ElementType.TYPE)

Have something found about the issue, that is seems, that is it because the lifecycle behaviour of JSF.
All values will be transferred seperatly from the post to the beans. So field-validation works fine, but
JSF doens't have any chance to validate the whole object.

Hibernate can do this of course when he tries to persist the object.

The solution to catch the exception doensn't work as listet. I have a typical architekt: ManagedBean -> ServiceClass (EJB) -> DAO (EJB) -> DatabaseCommit, but on ManagedBean side the only Exception i get is an:

javax.ejb.EJBException: Transaction aborted

somewhere in the stacktrace i can found the ValidationException... have you add a throws declaration to all your DAO-Methods, or how does it work in your case?

Thanks a lot
D