The reason OVal only uses named parameters when rendering error messages
is, that there is no reliable way to determine the parameter names in
every possible situation. Now if you think of reusing business model
classes between projects (e.g. reusing precompiled JARs) depending on
which parameter resolver you use different parameter names are resolved
this might break validation.
Therefore as long as Java does not provide a
java.lang.reflect.Method.getParameterNames() method I personally would
not rely on parameter names in validation rules - except we provide
something like a parameter-level @Named("parameter-name") annotation
which is mandatory in cases where you want to reference parameters by name.
Seb
On 16.09.2011 15:15, Emmanuel Bernard wrote:
On 7 sept. 2011, at 22:55, Sebastian Thomschke wrote:
> OVal currently uses parameter names only for error reporting and not to
> provide cross-parameter validations. To express preconditions the user
> is currently limited to work with an array containing the argument
> values only:
> @Pre("_args[0] != _args[1]", lang="groovy")
> void myMethod(String uniqueValue, String anotherUniqueValue) {
> // whatever....
> }
Do you remember why you have this limitation?
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev