Bean Validation 1.1

JavaEE 7 is just out and contains some nice surprises. Bean validation is one of them in my opinion.

Basically when looking quickly the new specifications you’ll think Bean Validation doesn’t change enough things to need to spend time on it but looking deeper it is not that sure.

I’ll try to put the major changes i found in some coming articles.

This first will just deal with a sample using CDI injections in a constraint validator.

 

Bean validation objects can be managed

By default constraint validator factory, constraint validator, message interpolator…are CDI managed. This mean you can now easily rely on CDI beans to validate your beans without using any library to get a CDI bean (was quite common to use Apache DeltaSpike and its BeanProvider).

Side note: next Apache DeltaSpike release will make it true for bean validation 1.0 and constraint validator.

Here is a sample which valid a String attribute doesn’t get as value a blacklist configured in ForbiddenValues annotation (let’s look a sample to make it concrete):

public class DangerousValueHolder {
    @ForbiddenValues({ "pwd", "password" })
    private String name = "bar";

    public String name() {
        return name;
    }

    public void rename(final String name) {
        this.name = name;
    }
}

The ForbiddenValues annotation looks like:

@Constraint(validatedBy = { FooBarValidator.class })
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD })
public @interface ForbiddenValues {
    String[] value() default { "password" };
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
    String message() default "{com.github.rmannibucau.bv.cdi.ForbiddenValues.message}";
}

The validator itself looks like (note it uses CDI directly):

public class FooBarValidator implements ConstraintValidator<ForbiddenValues, String> {
    private String[] forbidden;

    @Inject
    private ValidatorHelper bh;

    @Override
    public void initialize(final ForbiddenValues forbiddenValues) {
        forbidden = forbiddenValues.value();
    }

    @Override
    public boolean isValid(final String value, final ConstraintValidatorContext context) {
        return value == null || bh.isAllowed(value, forbidden);
    }
}

The ValidationHelper class is not that interesting it just does the following (just used it to show CDI was available):

public class ValidatorHelper {
    public boolean isAllowed(final String name, final String[] forbidden) {
        return !Arrays.asList(forbidden).contains(name);
    }
}

Basically we just want to be sure when we validate the DangerousValueHolder bean that name is neither “pwd” nor “password”.

Here is a sample arquillian test validating this behavior:

@RunWith(Arquillian.class)
public class ManagedConstraintValidatorTest {
    @Deployment
    public static Archive<?> war() {
        return ShrinkWrap.create(WebArchive.class, "managed-validator.war")
                .addPackage(DangerousValueHolder.class.getPackage())
                .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
    }

    @Inject
    private DangerousValueHolder holder;

    @Inject
    private Validator validator;

    @Test
    public void valid() {
        assertEquals(0, validator.validate(holder).size());
        holder.rename("password");

        final Set<ConstraintViolation<DangerousValueHolder>> constraintViolations = validator.validate(holder);
        assertEquals(1, constraintViolations.size());
    }
}

PS: this sample was executed against openwebbeans 1.2.1-SNAPSHOT and bean validation 2.0-SNAPSHOT