<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 11:35 AM, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On the subject, Gunnar and I were discussing three valid options to<br>
define a constraint as cross-parameter constraint:<br>
<br>
## @CrossParametersConstraint<br>
<br>
(first off I hate the name, can't we find a better one?)<br>
<br>
@Constraint(validatedBy=ObjectScriptAssert.class)<br>
@CrossParametersConstraint(validatedBy=ObjectScriptAssert.class)<br>
public @interface ScriptAssert { ... }<br>
<br>
## @Constraint for both<br>
<br>
@Constraint(validatedBy=ObjectScriptAssert.class<br>
validatedByForCrossParameters=ObjectScriptAssert.class)<br>
public @interface ScriptAssert { ... }<br>
<br>
## @Validates on ConstraintValidator<br>
<br>
<br>
@Constraint(validatedBy=ObjectScriptAssert.class)<br>
public @interface ScriptAssert { ... }<br>
<br>
@Validates({CROSS_PARAMETERS, ANNOTATED_ELEMENTS})<br>
public class ObjectScriptAssert implements<br>
ConstraintValidator<ScriptAssert,Object[]> { ... }<br>
<br>
## Thoughts<br>
<br>
I think I like @CrossParametersConstraints more than @Constraint for<br>
both as it makes things explicit and keep the simple use case as is.<br>
<br>
But I am intrigued by the @Validates option. In many ways, it's similar<br>
to how we resolve the right constraint validator based on the type. The<br>
only difference is that the @Validates annotation refines how Object[]<br>
should be interpreted. It "fits better" in my opinion.<br>
<br>
My concern around the latest option is that it forces us to be a<br>
subclass of ConstraintViolation for the foreseeable future including<br>
when we reopen the type-safe options we explored in<br>
<a href="http://beanvalidation.org/proposals/BVAL-232/" target="_blank">http://beanvalidation.org/proposals/BVAL-232/</a><br>
<br>
Thoughts and comments?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.<br>
<br></div><div>Matt<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Emmanuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Tue 2013-01-15 15:14, Gunnar Morling wrote:<br>
> 2013/1/15 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br>
><br>
> > I can live with that but we must make it crystal clear that in case of<br>
> > ambiguity, we raise an exception. Otherwise, someone changing the method<br>
> > sig might have some nasty surprises.<br>
> ><br>
><br>
> And which of the options<br>
><br>
> @CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)<br>
> @Constraint(validatedBy=MyGenericValidator.class)<br>
> public @interface MyConstraint { ... }<br>
><br>
> vs.<br>
><br>
> @Constraint(<br>
> validatedBy=MyGenericValidator.class,<br>
> crossParameterValidatorType=MyCrossParameterValidator.class<br>
> )<br>
> public @interface MyConstraint { ... }<br>
><br>
> would you prefer?<br>
><br>
> Personally I'd lean towards the latter, since there would be exactly one<br>
> meta-annotation denoting an annotation as constraint annotation type, with<br>
> all attributes for the required configuration.<br>
><br>
> If following the 2nd approach, we should IMO add a default clause to<br>
> validatedBy() (set to the empty array), allowing for<br>
> the convenient definition of cross-parameter only constraints. According to<br>
> [1] this change would be binary-compatible.<br>
><br>
> But this is no strong preference, I could also live with the two separate<br>
> annotations.<br>
><br>
> --Gunnar<br>
><br>
> [1]<br>
> <a href="http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods" target="_blank">http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods</a><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div></div>