group conversion conflict between bean properties constrained in different ways
by Matt Benson
Hi all,
Consider
InvalidGroupConversionInPropertyLevelOverridingTest#testGroupConversionsAreAdditiveAndExceptionIsThrownForMultipleConversionWithSameSource():
This test purports to enforce that a ValidationException is thrown because
a property specifies multiple group conversions from the Default group.
However, the example actually specifies one via the annotated getter, and
the other via the XML-configured field. I can't find that the spec is
perfectly clear on this, but it is clear that a property should be accessed
using the mechanism of constraint declaration. I don't recall where, but
the TCK tests proper validation of field vs. getter even when the objects
returned are different. I would therefore argue that there could be some
legitimate reason to apply a different group conversion to field vs.
getter, and that the test case should be changed to specify the XML
constraint via getter as does the User class definition overridden.
Matt
6 years
Question on Formal Group Definitions rules
by Matt Benson
Hi all,
With reference to spec v2.0 section 5.4.6, I am having trouble with item
3b, where a class X has no @GroupSequence annotation, among its Default
constraints are:
if X has a direct superclass Y, every constraint in the group Default
of Y *this
rule is necessary in case Y redefines the group Default*
Consider this with the concrete example in
GroupSequenceIsolationTest#testCorrectDefaultSequenceInheritance3(). Here
B3 extends A, whose @GroupSequence is defined as { Minimal, A }. Rule 4
says of a class X with a @GroupSequence annotation:
If X does have a @GroupSequence annotation, the group Default contains
every constraint belonging to every group declared by the @GroupSequence
annotation.
I thus conclude that Default contains for A: { Minimal, A } and that
Default for B3 should contain { B3 (per rule 3a), Minimal, A } and that the
validation performed at line 128 should detect violations at:
nickname (group B3)
size (group Minimal)
name (group A)
The assertions of the test, however, expect only the first two. Why is A
omitted? If the sequence defined by a superclass to be respected, where is
this specified? TBH I would think it would make sense, but my read of this
section specifically set me down a path of removing this behavior from the
Apache BVal codebase as I couldn't find a justification for it.
Thanks,
Matt
6 years
Clarification regarding executable parameter/return value validation with group sequence redefinition
by Matt Benson
Hello, I am encountering failures on three tests from
MethodValidationTest in the TCK:
* #constructorParameterValidationWithRedefinedDefaultGroupSequence()
* #methodParameterValidationWithRedefinedDefaultGroupSequence()
* #methodReturnValueValidationWithRedefinedDefaultGroupSequence()
In each case I am failing to pick up a @Size constraint from the
Default group of an Item parameter or Order return value. However, due
to the group sequence redefinition of Basic, Default on the bean class
in question I am confused as to why I am expected to pick up the
failures from the Default group after having encountered a @NotNull
constraint violation in the Basic group. Thanks for any help here.
Matt
6 years
ValueExtractionUnwrappingTest: quibble between spec and TCK
by Matt Benson
consider #validate_implicit_unwrapping_having_two_type_parameters_and_only_one_maximally_specific_value_extractor_marked_with_unwrap_by_default_is_ok():
What the spec says is:
...
If the constraint carries neither the Unwrapping.Unwrap nor the
Unwrapping.Skip payload:
If there is exactly one maximally-specific type-compliant value
extractor and this extractor is marked with @UnwrapByDefault, this
extractor is applied;
Otherwise, no value extractor is applied.
...
The test actually implements something more like:
If there is exactly one maximally-specific type-compliant value
extractor marked with @UnwrapByDefault, this extractor is applied,
etc.
The distinction is perhaps subtle, and I agree that the behavior
itself is reasonable; it just doesn't precisely agree with the current
wording, and I felt I should raise it as an issue.
Thanks,
Matt
6 years