[hibernate-dev] null values in validation

[Hardy Ferentschik]

> we managed to implement a first version of boolean composition for the
> validator, and it seems to require very few changes to the code.

Nice :)

> We also opened an issue on Jira about that.

I added some comments to  
http://opensource.atlassian.com/projects/hibernate/browse/HV-390
If you want to get some feedback regarding the code I suggest you attach a  
patch to the
issue or you use the new possibilities we have now through the move to git
(http://github.com/hibernate/hibernate-validator) by forking the validator  
repo.

> From the tests we ran, the constraints seem to be evaluated correctly,
> but we have some strange behaviour regarding the reporting of
> violations, which we are investigating.
> Reporting violations would also be an interesting subject of discussion
> in itself, since we cannot say anymore that a composed constraint fails
> if just one of the constraint
> composing it fails. We have to evaluate all the tree of constraints
> before knowing the final outcome (if it is a disjunction for example).
> In this case we thought it might be best to report everything as a
> single violation by default.

I think the composing constraint needs still to honor things like  
@ReportAsSingleViolation.
In case of a disjunction - if all validation fails I think you should get  
the violation
errors for all of them (unless @ReportAsSingleViolation is used). As soon  
as one
validation succeeds you don't get any validation error.

> Another thing we wondered about is the default behaviour of  built-in
> constraints when they validate null values. Are they supposed to succeed
> on null values by default?

That's a suggestion by the Bean Validation Specification. The spec says:

"While not mandatory, it is considered a good practice to split the core  
constraint
validation from the not null constraint validation (for example, an @Email  
constraint will return
true on a null object, i.e. will not take care of the @NotNull validation)
null can have multiple meanings but is commonly used to express that a  
value does not make sense, is not
available or is simply unknown. Those constraints on the value are  
orthogonal in most cases to other constraints.
For example a String, if present, must be an email but can be null.  
Separating both concerns is a
good practice."

--Hardy