<div dir="ltr"><div class="gmail_extra">Hi Hardy,</div><div class="gmail_extra"><br><div class="gmail_extra" style>To me your proposal looks like the way to go if we want to have this feature in. With giving 1.0 interpolation precedence over EL evaluation, also backwards compat. issue should be solved.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* Is the benefit offered by this solution big enough to introduce a dependency to another API/JSR?<br></blockquote><div><br></div><div style>This is the major question, and I haven't quite made up my mind.</div><div style>
<br></div><div style>We don't really use types from the EL API in BV, so AFAICS the dependency would not be there in terms of a Maven dependency from the BV API to the EL API, right? That is, BV providers could handle it optionally and require it only if EL expressions are actually used, or?</div>
<div><br></div><div style>In any case we're adding quite a lot just for the use case of the "inclusive" flag.</div><div style><br></div><div style>On a related note, WDYT about <a href="https://hibernate.onjira.com/browse/BVAL-339">https://hibernate.onjira.com/browse/BVAL-339</a>? I think if we add support for EL evaluation, it would make very much sense to allow for setting additional message parameters. At least we should add ConstraintValidatorContext#unwrap() to allow for BV providers adding proprietary means for doing so.</div>
<div style><br></div><div style>--Gunnar</div></div></div><br></div></div>