I'm currently updating our code from a mix of Hibernate Validator 3 and custom validation logic to the new version. All in all it looks very nice.

Some minor issues, that I've encountered so far:

Warnings

Section 2.1.1.3 mentions that payload() may be used to implement various severities (i.e. warnings). While that is better than nothing, it is much too limited; ConstraintValidator.isValid() should be able to set the severity, depending on the actual data being validated!

Example:

I need to validate bids for an auction. Placing a bid, that is below the best one is an error; placing a bid that is 100% larger than the best bid is a warning.

Of course, one could split that into two constraints, but that's not feasible for a larger data model with complex business rules.

Multiple Errors

It may be a good idea to explicitely mention, that ConstraintValidator.isValid() is allowed to report multiple errors at once, i.e. the code below triggers two constraint violations:



Message Interpolation

The default message interpolation is a bit limited. For advanced cases, it should be possible to:

• have the offending value interpolated into the message
• reference the name of the invalid property
• add arbitary parameters

Example:

When validating events, you would require that start date is before end date:



Without reference to the either the invalid value or the end date, the error message won't be very usable and would probably just say: "Start date is invalid" instead of "Start date must be before XX/XX/XXXX".

As a workaround I could make the message specific to this case ("Start date must be before end date"), but it would be nicer to have one generic error message, that can be reused for other date checks.

Cheers,
Stephan

i solved this by implementing my own message interpolator with an expression engine to handle parameters in the message from the bean so i do stuff like

error.message=date can not be before ${bean.endDate}

i do think that the payload idea is kinda lame, and i'm not sure why they didn't just use Strings to avoid the extension problem with annotation interfaces.

i went a different way and just created my own annotations and validators.

what i'd really like to see is access to the validation context before during and after validation so i can add objects for validating against as well as handles to the engine metadata and, like you said, the messages. because while i can accomplish most of what i wanted to do using expressions, it's still a little awkward.

also, i think it might be useful for constraint violations to have child violations, and if you have the error builder, you should be able to set severity there.