9:48 a.m.
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
10:33 a.m.
To comment on one of my own questions :-) :
On 17 Jan 2013, at 4:48 PM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
* 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.
One way around this would be to give potential BV 1.0 style message parameter
interpolation precedence over EL message expressions. In the case of
'${amount}' first an attempt must be made to interpolate '{amount}',
before interpolating '${amount}' as an EL expression. With this precedence rule
${amount}
would become e.g. $10 before EL evaluation would kick in.
--Hardy
10:59 a.m.
On Thu, Jan 17, 2013 at 10:33 AM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
To comment on one of my own questions :-) :
On 17 Jan 2013, at 4:48 PM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> * 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.
One way around this would be to give potential BV 1.0 style message
parameter interpolation precedence over EL message expressions. In the case
of
'${amount}' first an attempt must be made to interpolate '{amount}',
before interpolating '${amount}' as an EL expression. With this precedence
rule ${amount}
would become e.g. $10 before EL evaluation would kick in.
I think I like this direction.
Matt
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
5:47 a.m.
New subject: BVAL-192 and BVAL-223 - EL in message interpolator
Hi,
here is another update on EL as part of message interpolation. We have been discussing and
reviewing the
pull request [1] and it looks imo quite good. However, there are still some questions and
concerns.
Let's have a look at string formatting. Right now it looks like this:
${string:format(locale, 'Max %s', max)}.
Note the parameter 'locale'. Basically we request that the Locale passed to
MessageInterpolator#interpolate is bound to the
EL context as well and that this locale is used when calling string:format. Under the hood
this will call String#format(Locale, String, Object...).
This ensures that the right Locale is used during formatting.
Obviously from a user point of view the 'locale' parameter is unnecessary and it
would be nicer to just call ${string:format('Max %s', max)}.
In this case we cannot just specify that String#format(String, Object…) is bound to the EL
context. Instead it would be up to the implementation
to bind another helper function to the context which would one way or the other
(ThreadLocal!?) get hold of the right Locale to use for formatting.
I guess my concern with this approach is that it introduces a bit of voodoo into the
solution and it is not as transparent than the first solution.
A final approach would be to abandon the static function call and specify that a
java.util.Formatter (instantiated with the right Locale) is bound to
the EL context. In this case we have an instance call which looks somewhat like this
${formatter.format('Max %s', max)}. This looks nice as well.
However, all three solutions have another caveat. None of the above works with the
reference implementation of EL. As far as I know that is
javax.el:javax.el-api:2.2.4 (API) and org.glassfish.web:javax.el:2.2.4 (IMPL). For the
first two solutions to work you need at least a different
implementation. The glassfish implementation does not allow the binding of vararg
functions (the spec itself does not explicitly mention vararg
functions, just that functions must be public static methods). With JBoss EL and JUEL [2]
the use of vararg functions works fine.
To make use of the java.util.Formatter approach even the EL API needs to be exchanged.
Turns out the API in this case also contains a fair amount
of code, including the code to invoke bean methods. javax.el:javax.el-api:2.2.4 has a TODO
in its code to handle vararg methods, but right now
it throws an exception. The solution for this is to use the JUEL API which handles varargs
method properly.
For me it has a bad aftertaste that the EL functionality we want to use within Bean
Validation is neither properly specified in the EL spec nor is it working in the
reference implementation. It s not even clear which specification we could reference.
JSR-341 is supposed to be a standalone specification for EL, but
it seems quite inactive and I am not sure whether it will be part of EE 7. In this case we
would have to reference EL as part of JSR-245 [4].
Short summary:
Which syntax is preferable?
#1 ${string:format(locale, 'Max %s', max)}
#2 ${string:format('Max %s', max)}
#3 ${formatter.format('Max %s', max)}
Do we mind that vararg function calls is not working in the EL reference impl?
--Hardy
[1] https://github.com/beanvalidation/beanvalidation-spec/pull/41
[2] http://juel.sourceforge.net/index.html
[3] http://jcp.org/en/jsr/detail?id=341
[4] http://jcp.org/aboutJava/communityprocess/final/jsr245/
5:16 a.m.
Hi Hardy,
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.
* Is the benefit offered by this solution big enough to introduce a
dependency to another API/JSR?
This is the major question, and I haven't quite made up my mind.
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?
In any case we're adding quite a lot just for the use case of the
"inclusive" flag.
On a related note, WDYT about https://hibernate.onjira.com/browse/BVAL-339?
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.
--Gunnar
12:10 p.m.
I'd love too if we have time but let's see if we have some runway in 15
/ 20 days.
On Fri 2013-01-18 12:16, Gunnar Morling wrote:
Hi Hardy,
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.
* Is the benefit offered by this solution big enough to introduce a
> dependency to another API/JSR?
>
This is the major question, and I haven't quite made up my mind.
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?
In any case we're adding quite a lot just for the use case of the
"inclusive" flag.
On a related note, WDYT about https://hibernate.onjira.com/browse/BVAL-339?
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.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:28 p.m.
You can get unwrap() but do it on your spare time ;)
On Fri 2013-01-18 19:16, Gunnar Morling wrote:
2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I'd love too if we have time but let's see if we have some runway in 15
> / 20 days.
>
Yes, sure. But I think at least adding unwrap() shouldn't be a problem.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:35 p.m.
Working on this stuff on spare time? Who'd be that crazy to that ;)
2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
You can get unwrap() but do it on your spare time ;)
On Fri 2013-01-18 19:16, Gunnar Morling wrote:
> 2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
> > I'd love too if we have time but let's see if we have some runway in
15
> > / 20 days.
> >
>
> Yes, sure. But I think at least adding unwrap() shouldn't be a problem.
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:09 p.m.
I did most of my remarks in the pull request but here are some specific
to your questions.
On Thu 2013-01-17 16:48, Hardy Ferentschik wrote:
* Is the benefit offered by this solution big enough to introduce a
dependency to another API/JSR?
I think so, we have had many features tangentially related to improving
method interpolation and this addition will solve most if not all of
them in a very elegant way.
* 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
validatedValue has my preference too.
* I am proposing to bind String#format to the literal
'str:format'. Does this prefix sound ok, or should it be 'string:format'.
Small preference to string:format (for readability) but I won't fight.
* Is there a need to specify more functions which need to be
available in the EL context (on top of String#format)?
I'm tempted to say probably in the future. We should go for a simple
version now and think about more binding or even customized bindings in
a future rev of the spec.
* 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.
It seems $ is the standard so I'm ok to create some transitional
frictions for a better future. We did not make horrible mistakes in 1.0
so we have some good will to burn ;)
* 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4356
days inactive
4361
days old
beanvalidation-dev@lists.jboss.org
10 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Matt Benson