9:51 a.m.
Hi Emmanual,
I'll follow up later with some GroupSequence+inheritance info.
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 :)
Thanks,
Peter Davis
On Jan 4, 2012, at 5:57, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Also, IMHO it is overdue: *not* short circuiting (as today) is totally
redundant. Is there a reason this wasn't specified for BV 1.0?
*"When @ReportAsSingleViolation is present, short circuit."*
It's not mandatory but the spec recommend it
http://beanvalidation.org/1.0/spec/#constraintsdefinitionimplementation-c....
I'm pretty sure implementation providers do it. They should at
least :)
We can easily make it mandatory if people think it's a good idea but see
below first.
so
@Size(5)
@Pattern("[0-9]{5}")
@Constraint(validatedBy=BusinessPostCodeValidator.class) *// expensive;
query explodes if size > DB column length*
@ReportAsSingleViolation *// only query DB if @Size and @Pattern pass*
public @interface PostCode { ...
String message() default "not a valid postal code";
}
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 :)
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:
*"Allow @GroupSequence to be combined with interface inheritance in the
obvious way."*
(OK, "obvious" has a lot of nasty edge cases, but let me demonstrate why
this would be a good change:)
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:
@GroupSequence({Name1.class, Name2.class, Name3.class})
interface Names {
interface Name1 {}
interface Name2 {}
interface Name3 {}
}
@GroupSequence({Surname1.class, Surname2.class, Surname3.class})
interface Surnames {
interface Surname1 {}
interface Surname2 {}
interface Surname3 {}
}
interface BusinessValidations extends Names, Surnames {}
// A*t least the client wouldn't have to see all the ugliness.*
*// Maintenance, extensibility improved...but the following doesn't work!*
*// Currently no warning/error; only discover failure by test cases.*
validator.validate(account, BusinessValidations.class);
Peter, can I make you to work? :)
- can you provide the unit test you are talking about?
- can you point out the readings in the spec that make you think
inheritance and group sequence are not compatible?
- can you detail what you think is the obvious way in "Allow @GroupSequence
to be combined with interface inheritance in the obvious way"
It's probably better to do all this in a separate email thread.
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.]
Yes, can you open a thread on what you think are the other buggy
interactions.
Thanks for raising these issues
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev