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

Matt Benson mbenson at apache.org
Mon Jan 21 12:52:09 EST 2013


On Mon, Jan 21, 2013 at 11:35 AM, Emmanuel Bernard
<emmanuel at hibernate.org>wrote:

> On the subject, Gunnar and I were discussing three valid options to
> define a constraint as cross-parameter constraint:
>
> ## @CrossParametersConstraint
>
> (first off I hate the name, can't we find a better one?)
>
>     @Constraint(validatedBy=ObjectScriptAssert.class)
>     @CrossParametersConstraint(validatedBy=ObjectScriptAssert.class)
>     public @interface ScriptAssert { ... }
>
> ## @Constraint for both
>
>     @Constraint(validatedBy=ObjectScriptAssert.class
>                 validatedByForCrossParameters=ObjectScriptAssert.class)
>     public @interface ScriptAssert { ... }
>
> ## @Validates on ConstraintValidator
>
>
>     @Constraint(validatedBy=ObjectScriptAssert.class)
>     public @interface ScriptAssert { ... }
>
>     @Validates({CROSS_PARAMETERS, ANNOTATED_ELEMENTS})
>     public class ObjectScriptAssert implements
>         ConstraintValidator<ScriptAssert,Object[]> { ... }
>
> ## Thoughts
>
> I think I like @CrossParametersConstraints more than @Constraint for
> both as it makes things explicit and keep the simple use case as is.
>
> But I am intrigued by the @Validates option. In many ways, it's similar
> to how we resolve the right constraint validator based on the type. The
> only difference is that the @Validates annotation refines how Object[]
> should be interpreted. It "fits better" in my opinion.
>
> My concern around the latest option is that it forces us to be a
> subclass of ConstraintViolation for the foreseeable future including
> when we reopen the type-safe options we explored in
> http://beanvalidation.org/proposals/BVAL-232/
>
> Thoughts and comments?
>
>
So you're saying @Validates would eliminate the need for a separate
CrossParameterConstraintValidator interface?  FWIW, it seems to me that the
separate interface just feels more straightforward.

Matt


> Emmanuel
>
>
> On Tue 2013-01-15 15:14, Gunnar Morling wrote:
> > 2013/1/15 Emmanuel Bernard <emmanuel at hibernate.org>
> >
> > > 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.
> > >
> >
> > And which of the options
> >
> >
> @CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
> >     @Constraint(validatedBy=MyGenericValidator.class)
> >     public @interface MyConstraint { ... }
> >
> > vs.
> >
> >     @Constraint(
> >         validatedBy=MyGenericValidator.class,
> >         crossParameterValidatorType=MyCrossParameterValidator.class
> >     )
> >     public @interface MyConstraint { ... }
> >
> > would you prefer?
> >
> > Personally I'd lean towards the latter, since there would be exactly one
> > meta-annotation denoting an annotation as constraint annotation type,
> with
> > all attributes for the required configuration.
> >
> > If following the 2nd approach, we should IMO add a default clause to
> > validatedBy() (set to the empty array), allowing for
> > the convenient definition of cross-parameter only constraints. According
> to
> > [1] this change would be binary-compatible.
> >
> > But this is no strong preference, I could also live with the two separate
> > annotations.
> >
> > --Gunnar
> >
> > [1]
> >
> http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods
>
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130121/b974274a/attachment.html 


More information about the beanvalidation-dev mailing list