Yeah, the main issue is that the parameters are passed unescaped to the parser and the parser has several passes (e.g. one for the parameter syntax:
and one for the EL syntax:
. If the parameters contain some special characters, it might end up badly because on the parameter pass, the regexp parameter is included unescaped and when we do the EL pass, the message is not a valid one anymore if the regexp parameter contains special characters (typically {, } or $). Historically, we have to do these different passes to maintain the compatibility with Bean Validation 1.0 (the EL syntax is an addition for Bean Validation 1.1). We can't change this historic behavior so we added the possibility to provide additional message parameters and we pass an escaped version of the regexp via this mechanism. There were other possibilities for the fix but it's the only one we found that could maintain backward compatibility. I hope I'll be able to provide a shorter fix for 5.4. Btw, I think you can probably work around your issue by using your own composing constraint overriding the message using the EL syntax for the regexp parameter:
This way, it would be replaced in the last pass and I think it shouldn't trigger an error (I haven't tested it though). |