[bv-dev] Distinguishing cross-parameter and generic constraints

Hardy Ferentschik hardy at hibernate.org
Tue Jan 15 05:57:50 EST 2013


Hi,

I think with the additional IMPLICIT option the cases where the user actually needs to specify 'validationAppliesTo' is really minimised. 
+1 for this option

--Hardy

On 15 Jan 2013, at 10:53 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> 2013/1/14 Emmanuel Bernard <emmanuel at hibernate.org>
> After letting this idea rest for a while, I still like it.
> 
> In the issue, you also proposed to go a step further and get rid of
> @CrossParameterConstraint altogether. I sort of remember not being keen
> on the idea to protect future evolutions on the type-safe
> cross-parameter way. Have you thought about it more? What is your
> opinion?
> 
> Yes, I still like the idea of having only the @Constraint annotation for defining constraints, but one problem I see is that one can not specify different validators for return value arrays and method argument arrays in cases like this:
> 
>     @MyCustomConstraint(validationAppliesTo = PARAMETERS)
>     public void foo(int p1, int p2) { ... }
> 
>     @MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
>     public Object[] bar() { ... }
> 
> With the different annotations @Constraint and @CrossParameterConstraint, two different validators (both parameterized with <MyCustomConstraint, Object[]>) could be specified here. Not sure, how relevant this is in reality, though.
> 
> An alternative would be to extend @Constraint to accommodate the specification of generic validator(s) and/or a cross-parameter validator:
> 
>     public @interface Constraint {
>         Class<? extends ConstraintValidator<?, ?>>[] validatedBy() default {};
>         Class<? extends ConstraintValidator<?, ?>> crossParameterValidatorType() default ConstraintValidator.class;
>     }
> 
> The same rules would apply, i.e. the constraint must have a "validationAppliesTo" attribute in case validators for both cases are specified.
> 
> Thinking about Matt's IMPLICIT suggestion a bit more, I guess we could even limit the cases where the constraint user must actually set the "validationAppliesTo" attribute to those cases where it can't be inferred automatically:
> 
>     //"validationAppliesTo" not required, since method is void
>     @MyCustomConstraint
>     public void foo(int p1, int p2) { ... }
> 
>     //not required, since method has no parameters
>     @MyCustomConstraint
>     public Object[] bar() { ... }
> 
>     //"validationAppliesTo" required if constraint has a (generic) validator for Baz and cross-param validator for Object[]
>     @MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
>     public Baz foo(int p1, int p2) { ... }
> 
>     //"validationAppliesTo" required if constraint has a (generic) validator for Object[] and cross-param validator for Object[]
>     @MyCustomConstraint(validationAppliesTo = PARAMETERS)
>     public Object[] foo(int p1, int p2) { ... }
> 
> The ValidationTarget enum would have the values IMPLICIT (default), ANNOTATED_ELEMENT and PARAMETERS.
> 
> WDYT?
> 
> --Gunnar
> 
>  
> 
> Emmanuel
> 
> On Mon 2013-01-07 23:21, Gunnar Morling wrote:
> > Hi all,
> >
> > As per the latest spec draft, a constraint must be either a cross-parameter
> > *or* a generic constraint, but not both at the same time, as otherwise it
> > would be ambiguous whether a constraint on a method refers to the method
> > parameters or return value.
> >
> > Most of the time this does not really pose a limitation, but some
> > constraints actually might be both, cross-parameter *and* generic,
> > depending on the specific context. Examples are @ScriptAssert in Hibernate
> > Validator or generic constraints such as this:
> >
> > @EqualPasswords
> > public void register(String userName, String password, String
> > confirmedPassword) {
> > }
> >
> > @EqualPasswords
> > public class ResetPasswordRequest {
> >     String userName;
> >     String password;
> >     String confirmedPassword;
> > }
> >
> > Based on a recent BVAL issue [1], I'm proposing to introduce a special
> > constraint annotation attribute, "validationAppliesTo", allowing to specify
> > the required behavior at the usage site:
> >
> > @EqualPasswords(validationAppliesTo=PARAMETERS)
> > public void register(String username, String password, String
> > confirmPassword) {
> > }
> >
> > @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
> > public class ResetPasswordRequest {
> >     String password;
> >     String confirmedPassword;
> > }
> >
> > The following rules would apply:
> >
> > * If a constraint is annotated with @Constraint and
> > @CrossParameterConstraint, it must define a member "validationAppliesTo".
> > The default value should be ANNOTATED_ELEMENT.
> > * If a constraint is annotated with only one
> > of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"
> > member doesn't have any special effect
> > * Specifying validationAppliesTo=PARAMETERS anywhere except a method causes
> > ConstraintDeclarationException
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > [1] https://hibernate.onjira.com/browse/BVAL-340
> 
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev




More information about the beanvalidation-dev mailing list