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

[Emmanuel Bernard]

I can live with that but we must make it crystal clear that in case of
ambiguity, we raise an exception. Otherwise, someone changing the method
sig might have some nasty surprises.

Emmanuel

On Tue 2013-01-15 11:57, Hardy Ferentschik wrote:
> 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
> 
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev