[bv-dev] Re-definition of default group sequences in inheritance hierarchies

[Gunnar Morling]

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 at 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/src/main/java/org/hibernate/beanvalidation/tck/tests/constraints/groups/groupsequenceisolation/GroupSequenceIsolationTest.java#L134
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121108/ccfd433a/attachment-0001.html