Bean Validation 1.1 Beta 4 - issue smashing edition

by Emmanuel Bernard on 15 Feb 2013 release

Our proposed final draft is due soon but we did one last drop of the specification and the API jar. We worked all over the board (and the clock) but the most notable improvements are:

Improvements on the CDI integration section

We made it much more descriptive of the expected behavior instead of imposing an implementation pattern. We have also added the method and constructor interception priority as defined in the Java EE specification and the interceptor specification in particular.

Thanks Pete for your help.

Remove the link between the Node API and the metadata API

This is something we could not make work, so we fall back into a more redundant but we think cleaner design. We also made the node builder API easier to use despite the increased number of node types.

//Cross-parameter constraint on a method
//mergeAddresses(Map<String,Address> addresses, Map<String,Address> otherAddresses)
//Build a constraint violation on the default path + "otherAddresses["home"]
//ie. the Address bean hosted in the "home" key of the "otherAddresses" map parameter
context.buildConstraintViolationWithTemplate(
        "Map entry home present in both and does not match")
                .addParameterNode(1)
                .addBeanNode()
                    .inIterable().atKey("home")
                .addConstraintViolation();

Clarification around method validation (metadata, cross-parameter, reports)

We now have an explicit cross-parameter concept materialized in the metadata API. It makes for a more regular and easier to browse API. ConstraintViolation has also seen some improvements and adaptations to make it ready for prime - method validation - time.

Mark a method as (non) validated

We slightly improved @ValidateExecutable to be more friendly when put on a specific method. To force a getter to be validated or to force a method to not be validated is now more readable.

public class Operations {
    @ValidateExecutable
    @Status
    public String getStatus() { ... }

    @ValidateExecutable(ExecutableType.NONE)
    public void apply(@Valid Operation operation) { ... }
}

Review

Let us know what you think.

You can access the specification here. All changes are marked with a different color. Green for additions, yellow for changes and struck through red for removals . This will help you see what has changed precisely.

Please send us your remarks and comments:

If you want to go to the next step and contribute, send us an email to the mailing list and read how to contribute.