[bv-dev] BVAL-192 and BVAL-223

[Hardy Ferentschik]

Hi all,

as you remember prior to the Holidays we have been discussing BVAL-192 [1] - the addition of an 'inclusive' flag to @DecimalMin/Max.
Adding the additional parameter was not a big issue, but rendering the right constraint error message was tricky, because the message varies depending 
on the value of the flag. 

One solution we discussed was to introduce Expression Language (JSR 341) into the message interpolation algorithm. In the case of
@DecimalMin/Max this would allow for something like this: "Must be greater than ${inclusive == true ? 'or equal to' : ''} {value}"

Using EL we can also bind the validated value itself into the EL context and allow message formatting along these lines: ${str:format("%1$5f", validatedValue}
Provided str:format is bound to the String.format method. This would address BVAL-223 [2]

I created a pull request for the BV spec [3] outlining the changes to the default message interpolation algorithm. It would be great to get some feedback
on this. 

Here are some questions I am in particular wondering about:

* Is the benefit offered by this solution big enough to introduce a dependency to another API/JSR?
* I am proposing to bind the validated value to the string literal 'validatedValue'. Is this a good name? 'value' would be shorter, but would conflict with
 the default annotation parameter name
* I am proposing to bind String#format to the literal 'str:format'. Does this prefix sound ok, or should it be 'string:format'. 
* Is there a need to specify more functions which need to be available in the EL context (on top of String#format)?
* Using the ${expression} syntax causes a backward compatibility issue with BV 1.0 where '$' was used as literal, e.g. ${amount} would be $10 in BV 1.0
  whereas now it would be just 10. Maybe '#' would be a better marker for EL expressions or to be 100% correct a configuration flag would be needed.
* Last but not least, how should be handle invalid EL expressions or expressions which reference non existent properties. For the user it might be best
 to catch any EL based exception and just return the un interpolated expression (the actual impl could log a warning). If we propagate exceptions might have
 to deal with exception based on poor message/expression design.

Looking forward to get some feedback,
Hardy


[1] https://hibernate.onjira.com/browse/BVAL-192
[2] https://hibernate.onjira.com/browse/BVAL-223
[3] https://github.com/beanvalidation/beanvalidation-spec/pull/41