Hi @Gunnar Morling, sure.

Actually, the example from @Marco Janc in this issue would work as well, but let me give another example:

class Foo {
  @NotNull Bar bar;

  @AssertTrue
  boolean hasValidBar() {
    return bar.value.equals(42);
  }   
}

class Bar {
  Integer value;
}

If we inspect the following Foo instance (shown as json):

{
  "bar" : {
    "value": 43
  }
}

Then the @AssertTrue validation will fail because the value in bar is not 42. However, if we pass the following instance:

{
  "bar" : null
}

then it would be nice if the validator returns that the @NotNull constraint was violated. Instead, a ValidationException is thrown because the @AssertTrue validation resulted in a NullPointerException.

My suggestion is to swallow those exceptions if there are other constraint violations. In this case that would mean that the framework would return that a single constraint was violated.

Only in case when there are NO constraint violations but one or more constraint validations yield a ValidationException does the framework throw out the ValidationException. Here's an example of that:

{
  "bar" : {
    "value": null
  }
}

In this case the @AssertTrue validation will also result in a ValidationException but there are no other constraint violations. In that case the framework should not swallow the ValidationException but throw it in the same way as it does currently.

This solution works no matter the validation order and "fail-fast" is not required. If you check the ValidatorImpl I've attached you can see I made 2 small changes in methods validateConstraintsForSingleDefaultGroupElement(...) and validateMetaConstraints(...). While looping over the constraints any ValidationException is caught. The ValidationException is only thrown if there are no other violations.

Hope this clarified things. I've tested my solution in a large project containing hundreds of annotated beans and it seems to do the trick. Let me know what you think.