Re-definition of default group sequences in inheritance hierarchies
by Gunnar Morling
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...
13 years, 11 months
Presentation on Bean Validation 1.1
by Emmanuel Bernard
Hi all,
I have given a few talks around Bean Validation but cannot cover them
all.
Last in line, I have received an invite from the Utah Java User Group to
give a presentation. That's quite far off my homebase. Is anyone here
interested in giving a talk about Bean Validation over there?
I can share my slides if needed.
Emmanuel
13 years, 11 months
Method validation BVAL issue
by Gunnar Morling
Hi all,
This is to let you know that I've created a new umbrella issue for the
remaining tasks around method validation, BVAL-329 [1].
I've resolved the previous one (BVAL-272) and moved all open sub-tasks over
to the new issue. Please add any new to do's regarding method validation as
sub-task to BVAL-329.
While moving the tasks I've noticed that nearly all finished BVAL issues
are "Resolved" but not "Closed".
My understanding of the JIRA process is that an issue gets resolved when
the actual work is done and that it is closed once it is
delivered/released. So I think we should set all resolved issues to closed
except those resolved after PR1. I can do that if no-one objects.
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-329
13 years, 11 months
