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) { = name;

The ForbiddenValues annotation looks like:

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

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

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

    private ValidatorHelper bh;

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

    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:

public class ManagedConstraintValidatorTest {
    public static Archive<?> war() {
        return ShrinkWrap.create(WebArchive.class, "managed-validator.war")
                .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");

    private DangerousValueHolder holder;

    private Validator validator;

    public void valid() {
        assertEquals(0, validator.validate(holder).size());

        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


4 thoughts on “Bean Validation 1.1

    1. rmannibucau Post author

      this is either a bug in your app or in glassfish. However by default ValidatorHelper wouldn’t be scanned since it is not annotated and that’s the CDi 1.1 default. Add @ApplicationScoped and it would work (or configure CDI to scan it)

      1. rmannibucau Post author

        Can be a bug in GlassFish too. I tested it on Apache BVal and TomEE (so with CDI 1.0 rules) and all went smoothly

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s