<html><head></head><body bgcolor="#FFFFFF"><div>Hi Emmanual,</div><div><br></div><div>I&#39;ll follow up later with some GroupSequence+inheritance info. </div><div><br></div><div>Re: ordering, my example does not depend in source order (I&#39;m aware it&#39;s not reliable), because I don&#39;t care whether @Size or @Pattern is checked first or all. They are both cheap. I care about the parent (the composed validation) but unfortunately I can confirm HV4.2 reference implementation doesn&#39;t follow the &quot;recommendation&quot; in the spec. I can also confirm it has been a problem for us :)</div>
<div><br></div><div>Thanks,</div><div>Peter Davis</div><div><br>On Jan 4, 2012, at 5:57, Emmanuel Bernard &lt;<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite">
<div><div><blockquote type="cite"><div style="word-wrap:break-word"><div>Also, IMHO it is overdue: <u>not</u> short circuiting (as today) is totally redundant.  Is there a reason this wasn&#39;t specified for BV 1.0?</div>
<div><br></div><blockquote class="webkit-indent-blockquote" style="margin:0 0 0 40px;border:none;padding:0px"><div><b>&quot;When @ReportAsSingleViolation is present, short circuit.&quot;</b></div></blockquote></div></blockquote>
<div><br></div><div>It&#39;s not mandatory but the spec recommend it <a href="http://beanvalidation.org/1.0/spec/#constraintsdefinitionimplementation-constraintcomposition">http://beanvalidation.org/1.0/spec/#constraintsdefinitionimplementation-constraintcomposition</a> (note). I&#39;m pretty sure implementation providers do it. They should at least :)</div>
<div><br></div><div>We can easily make it mandatory if people think it&#39;s a good idea but see below first.</div><br><blockquote type="cite"><div style="word-wrap:break-word"><div>so</div><blockquote class="webkit-indent-blockquote" style="margin:0 0 0 40px;border:none;padding:0px">
<div>@Size(5)</div><div>@Pattern(&quot;[0-9]{5}&quot;)</div><div>@Constraint(validatedBy=BusinessPostCodeValidator.class) <i>// expensive; query explodes if size &gt; DB column length</i></div><div>@ReportAsSingleViolation <i>// only query DB if @Size and @Pattern pass</i></div>
<div>public @interface PostCode { ...</div><div>    String message() default &quot;not a valid postal code&quot;;</div><div>}</div></blockquote><div><br></div></div></blockquote><div><br></div><div>That won&#39;t work because annotations are not returned by the reflection API in the order they are declared in the source file. I&#39;ve had some fun with that in the past on fields and methods :)</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><div><br></div><div>If different messages are needed, then @GroupSequence works but as Cemo says is unwieldy, and furthermore in practice breaks when combined with group inheritance (which is very natural and useful).  So...2nd suggestion:</div>
<div><br></div><blockquote class="webkit-indent-blockquote" style="margin:0 0 0 40px;border:none;padding:0px"><div><b>&quot;Allow @GroupSequence to be combined with interface inheritance in the obvious way.&quot;</b></div>
</blockquote><div><br></div><div>(OK, &quot;obvious&quot; has a lot of nasty edge cases, but let me demonstrate why this would be a good change:)</div><div><br></div><div>Currently the following gives wacky and IMHO wrong results (test case available on request).  A close reading of BV 1.0 spec shows @GroupSequence and inheritance are incompatible...but the interactions are not intuitive:</div>
<div><br></div><blockquote class="webkit-indent-blockquote" style="margin:0 0 0 40px;border:none;padding:0px"><div>@GroupSequence({Name1.class, Name2.class, Name3.class})</div><div>interface Names {</div><div>    interface Name1 {}</div>
<div>    interface Name2 {}</div><div>    interface Name3 {}</div><div>}</div><div><br></div><div><div>@GroupSequence({Surname1.class, Surname2.class, Surname3.class})</div></div><div><div>interface Surnames {</div><div>    interface Surname1 {}</div>
<div>    interface Surname2 {}</div><div>    interface Surname3 {}</div><div>}</div></div><div><br></div><div>interface BusinessValidations extends Names, Surnames {}</div><div><br></div><div>// A<i>t least the client wouldn&#39;t have to see all the ugliness.</i></div>
<div><i>// Maintenance, extensibility improved...but the following doesn&#39;t work!</i></div><div><i>// Currently no warning/error; only discover failure by test cases.</i></div><div>validator.validate(account, BusinessValidations.class);</div>
</blockquote><div><br></div></div></blockquote><div><br></div><div>Peter, can I make you to work? :)</div><div><br></div><div>- can you provide the unit test you are talking about?</div><div>- can you point out the readings in the spec that make you think inheritance and group sequence are not compatible?</div>
<div>- can you detail what you think is the obvious way in &quot;Allow @GroupSequence to be combined with interface inheritance in the obvious way&quot;</div><div><br></div><div>It&#39;s probably better to do all this in a separate email thread.</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><div><br></div><div>From my perspective proposal #1 would get 80% of the way, and #2 would get the rest as well as solve some very wacky (buggy?) interactions I&#39;ve observed in my year+ of using BV 1.0.  [There are other, more subtle ways that @GroupSequence messes with inheritance -- even when used in unrelated groups passed to #validate(...) -- that I&#39;d be happy to move to a different topic.]</div>
</div></blockquote><div><br></div><div>Yes, can you open a thread on what you think are the other buggy interactions.</div></div><br><div>Thanks for raising these issues</div><div><br></div><div>Emmanuel</div></div></blockquote>
<blockquote type="cite"><div><span>_______________________________________________</span><br><span>beanvalidation-dev mailing list</span><br><span><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span><br></div></blockquote></body></html>