Hi Marc Schipperheyn,

I am not so sure I am completely following this issue. For example I don't quite understand what you mean with:

forces recursive message interpolation and combines this with a dependency on missing message value exceptions

And what does that mean:{

In Spring you can configure a message source to return the value of the message key if the key isn't found.

Are you saying that in Spring if you have a parameter

which can not be resolved you get just the parameter name back (foo) w/o the {}. Which part of Spring is that and how it is configured?

So you basically expect that:

Must be between {min} and {max}

returns

Must be between min and max

if there are no parameters min and max. If this is what Validator did before, I think you relied on some bad implementation or even bug. The spec might be a bit vague on the exact behaviour when it comes to message parameters of this form, but with the new EL expression it even explicitly states:

If an exception occurs during message interpolation, e.g. due invalid expressions or references to an unknown property, the message expression stays unchanged.

In this light it seems more consistent that

or

also stay unchanged if no substitution takes place.

The relevant Bean Validation spec section is here. It is not explicit on this particular case, but I think the behaviour is more consistent now.

For now, I'll just copy-hack the message interpolator.

Right, you can always use your own interpolator, but personally I am not sure whether I would like to rely on this behaviour at all. There is always the option to make this somehow configurable (as a Hibernate Validator specific feature), but then you need to convince me first that this is a good use case