You are hitting a rather uncommon corner case here. It seems you have the EL API on your classpath but not an implementation (e.g. the reference implementation provided by Glassfish). Previously, the presence of EL was only checked by testing wether a specific class from the public API is available but we didn't try to actually bootstrap any expression factory. This is why your setup worked before.

Now the bug that we fixed was that we also triggered that check of the EL class even if ParameterMessageInterpolator is configured. Of course that was not sensible as you specifically would use that interpolator to avoid the need for EL. At the same time the check has been reworked in a way that the EL factory now actually is bootstrapped when the default message interpolator is used. So in the case of your set-up, if you were to use @DecimalMax which is using an EL expression in its message with 5.2.4, you'd get an uninterpolated message (and a warning in the log) which was not desirable. Whereas now you'll get an early error during bootstrapping which is what you see.

Your way forward is this:

• Use ParameterMessageInterpolator if you don't need EL for your messages (i.e. no @DecimalMax/Min with their default messages, no EL expressions in any other messages you define)
• Provide not only the EL API but also an implementation, e.g. by adding org.glassfish:javax.el:3.0.1-b08 as a dependency which contains API and the reference implementation.

I hope that clarifies things; if you need further advice, just let us know.