<html><head></head><body bgcolor="#FFFFFF"><div>Hi Emmanual,</div><div><br></div><div>I'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'm aware it's not reliable), because I don'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't follow the "recommendation" 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 <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> 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'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>"When @ReportAsSingleViolation is present, short circuit."</b></div></blockquote></div></blockquote>
<div><br></div><div>It'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'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'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("[0-9]{5}")</div><div>@Constraint(validatedBy=BusinessPostCodeValidator.class) <i>// expensive; query explodes if size > 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 "not a valid postal code";</div><div>}</div></blockquote><div><br></div></div></blockquote><div><br></div><div>That won't work because annotations are not returned by the reflection API in the order they are declared in the source file. I'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>"Allow @GroupSequence to be combined with interface inheritance in the obvious way."</b></div>
</blockquote><div><br></div><div>(OK, "obvious" 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't have to see all the ugliness.</i></div>
<div><i>// Maintenance, extensibility improved...but the following doesn'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 "Allow @GroupSequence to be combined with interface inheritance in the obvious way"</div><div><br></div><div>It'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'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'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>