8:30 a.m.
Hi Hardy,
thanks for these pointers. I'm confused by the description of this case (3)
in HV-164, though. There it says:
"when validating Default.class on B, you need to validate sequentially
* @Max on size (Minimal)
* @Size on name (A)
* and in // at any time @Size on nickname (B group)."
What does "in/at any time" mean here?
The description further says:
"Likewise @Max on size could fail [...] [and] @Size on nickname (B) will
not [be validated] as it has to be validated only if Minimal constraints
pass".
But the test in the TCK expects two violations, one for @Max on size and
one for @Size on nickname. This seems to be contradictory.
My actual question is also why the rules are like this. So what's the
rationale of not applying the default sequence from the super type to the
constraints of the sub-type?
Whenever I'm starting to think about re-defined default group sequences,
I'm getting confused :)
--Gunnar
2012/11/8 Hardy Ferentschik <hardy(a)hibernate.org>
Hi,
The isolation of the group sequence is captured in this discussion [1] and
this HV issue [2]
--Hardy
[1] http://lists.jboss.org/pipermail/hibernate-dev/2009-May/003891.html
[2] https://hibernate.onjira.com/browse/HV-164
On 8 Jan 2012, at 1:15 PM, Gunnar Morling wrote:
> Hi experts,
>
> I've got a question regarding the re-definition of default group
sequences in inheritance hierarchies, more specifically about the test
method GroupSequenceIsolationTest#testCorrectDefaultSequenceInheritance3()
in the TCK [1].
>
> There are the following two classes and validation groups defined:
>
> @GroupSequence({ Minimal.class, A.class })
> public class A {
>
> @Max(value = 10, groups = Minimal.class)
> int size;
>
> @Size(max = 20)
> String name; //A group
> }
>
> interface Minimal {}
>
> interface Heavy {}
>
> public class B3 extends A {
>
> @SafeEncryption(groups = Heavy.class)
> String encryptionKey;
>
> @Size(max = 20)
> String nickname;
> }
>
> The test looks like this:
>
> B3 b = new B3();
>
> //all values invalid
> b.name = "this name is too long";
> b.nickname = "and this nickname as well";
> b.size = 20;
> b.encryptionKey = "not safe";
>
> Set<ConstraintViolation<B3>> violations = validator.validate( b );
> assertCorrectNumberOfViolations( violations, 2 );
> assertCorrectConstraintTypes( violations, Max.class, Size.class );
> assertCorrectPropertyPaths( violations, "size", "nickname" );
>
> So, based on the assertions, the re-defined default group sequence only
applies to the constraints defined on A but not on those defined on B3.
>
> I'm wondering why that is. Intuitively I would have expected that the
re-definition of the default group applies to all types of the hierarchy,
so one can re-define the default group at the top of an inheritance
hierarchy.
>
> Does anyone know/remember why the behavior is defined like it is?
>
> Thanks,
>
> --Gunnar
>
> [1]
https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr...
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev