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, 8 months
Questions on TCK SequenceResolutionTest
by Matt Benson
Hi all,
I'm having trouble recognizing what about TestEntity is supposed to
trigger the GroupDefinitionException in
#testInvalidDefinitionOfDefaultSequenceInEntity() (for convenience,
TestEntity is at [1]). The name of the test case suggests that the
problem would be on TestEntity's own @GroupSequence, which aside from
the order of the specified groups looks more or less like example 5.11
near [2]. This suggests that the test case is imperfectly named (the
name also seems misaligned with the accompanying @SpecAssertions) and
the focus intends to be on the Complete group of which validation is
attempted as the last activity of the test. Complete again looks
topographically identical to example 5.10 in the previous section of
the specification, which suggests that there is nothing inherently
wrong with it. I can appreciate that, when taking TestEntity's
redefinition of Default into account, Complete's sequence evaluates to
[ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is
clearly repetitive/redundant, but is it really to be considered
cyclical? Is there any danger of infinite recursion and, if so, how?
Is there some other problem I have missed here?
Thanks,
Matt
[1] https://github.com/beanvalidation/beanvalidation-tck/blob/2.0/tests/src/m...
[2] http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationproces...
6 years, 8 months
Validator#validateValue() with incompatible Object specified
by Matt Benson
Hi, this comes from TCK
ValidateValueTest#testValidIsNotHonoredValidateValue() . The test
asserts that no constraint violations (and no exceptions) will be
generated when specifying an Order as a proposed value for a property
that includes a Set of Orders. The name of the test suggests to me,
however, that the Validator is expected to transparently treat the
Order as a single-element Set and simply show that validation of that
set is not cascaded. Is this the case, or is the test actually showing
that any incompatible value will be treated as raising no violations
(and is therefore imperfectly named)? In either case, where does the
specification dictate this behavior? Apache BVal has always raised an
IllegalArgumentException if the specified value is not compatible, but
its justification for having done so appears to be an artifact of an
incorrect interpretation of the Javadoc of #validateValue(): "not a
valid object property" was mistakenly applied to the "value" parameter
instead of to the "propertyName" parameter as a careful reading
reveals (IMO) is proper. But this exposes what seems to be an omission
in the spec: what *is* the proper behavior when validation of an
incompatible value is requested? And let's not forget the unclear
nature of the test in question: is "order" a compatible value by
virtue of being checked against a Set of its type (and, if so, why?),
or is "order" an incompatible value that the Validator quietly
abstains from checking at all?
Thanks,
Matt
6 years, 8 months
Apparent TCK misuse of ValidationTarget.PARAMETERS
by Matt Benson
Consider test ValidationInterceptorPriorityTest#testValidationInterceptorHasPriority4800():
The example validates that the parameter to
CalendarService#createEvent(String) satisfies @CustomConstraint.
However, the sole validator declared for @CustomConstraint,
CustomConstraintValidator, is marked as supporting
ValidationTarget.PARAMETERS . In turn, the spec and Javadoc clearly
indicate that ValidationTarget.PARAMETERS indicates cross-parameter
validation. I think this one would be satisfied either by simply
removing @SupportedValidationTarget from the CV impl, or by adding
ANNOTATED_ELEMENT.
Thanks,
Matt
6 years, 8 months
TCK constraint composition problem WAS Size validator for int
by Matt Benson
Okay, after digging a bit deeper I have come up with the following list of
affected tests:
org.hibernate.beanvalidation.tck.tests.metadata.PropertyDescriptorTest:
#testGetGroupConversionsForField
#testGetGroupConversionsForProperty
#testGetGroupConversionsReturnsEmptySet
#testIsCascaded
#testPropertyName
org.hibernate.beanvalidation.tck.tests.metadata.ConstraintDescriptorTest:
#testAnnotationAndMapParametersReflectParameterOverriding
#testComposingConstraints
#testComposingConstraintsPayload
#testGetGroups
#testGetGroupsOnInterface
#testGetGroupsWithImplicitGroup
#testGetMessageTemplate
#testGetValidationAppliesTo
#testGetValidationAppliesToFromComposingConstraint
#testGetValidationAppliesToReturnsNull
#testPayload
#testReportAsSingleViolation
org.hibernate.beanvalidation.tck.tests.metadata.BeanDescriptorTest:
#testGetConstraintsForUnConstrainedProperty
#testGetElementClassReturnsBeanClass
#testIsBeanConstrainedDueToConstraintOnInterface
#testIsBeanConstrainedDueToValidAnnotation
These tests have in common the fact that they use bean classes derived from
the org.hibernate.beanvalidation.tck.tests.metadata.Person interface, whose
#getAge() method declares @CustomConstraint, which inherits @Size as a
composing constraint via @CustomComposingConstraint.
Section 3.3 of the spec says:
The type upon which composed constraint is placed must be compatible with
all constraints (composing and composed).
I therefore conclude that the constraint applied to Person#getAge() is
incorrectly composed.
Thanks,
Matt
*CONFIDENTIALITY NOTICE: This e-mail, including any attachments, may
contain confidential, privileged and/or proprietary information which is
solely for the use of the intended recipient(s). Any review, use,
disclosure or retention by others is strictly prohibited. If you are not an
intended recipient, please contact the sender and delete this e-mail, any
attachments and all copies.*
Permanent General Assurance Corporation | Permanent General Assurance
Corporation of Ohio | The General Automobile Insurance Company, Inc. | Old
American County Mutual Fire Insurance Company | Home Office: 2636 Elm Hill
Pike, Nashville, TN 37214
On Fri, Mar 23, 2018, 3:35 AM Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
> Hi Matt,
>
> On Thu, Mar 22, 2018 at 11:12 PM, Matt Benson <mbenson(a)apache.org> wrote:
>
>> Yeah, this is weird. Elsewhere there is a test that specifically looks
>> for there *not* being a Size validator for int. I will do some more
>> research on this and report back tomorrow.
>>
>
> FWIW, we don't have one in HV so the TCK cannot expect the impl to have
> one.
>
> --
> Guillaume
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6 years, 9 months
Size validator for int
by Matt Benson
Several TCK tests rely on this; however I have never seen anything in the
spec to dictate that this should be covered. Having said that, it is of
course extremely easy to implement this validation for Number, so I am
happy to test this as a missing item in the spec as opposed to a problem in
the TCK.
Matt
6 years, 9 months
TCK bootstrap - ExecutableType.NONE
by Matt Benson
I would challenge
BootstrapConfigurationWithValidatedExecutableTypesContainingNONETest
as defying the specification. The current version says at
http://beanvalidation.org/2.0/spec/#integration-general-executable and
in the code for ExecutableType that NONE is essentially ignored in the
presence of other types (and effectively, always). I see nothing to
dictate that NONE should be treated differently in the XML descriptor
than elsewhere.
WDYT?
Thanks,
Matt
6 years, 9 months
TCK: LegacyValidOnContainerCascadingTest
by Matt Benson
Hi all,
This issue could be similar to my last one. On
#testValidOnListAndOnTypeArgumentWithGroupConversions() the expectation is
the single violation on visitors[0].name with the Default group. My
implementation converts Default to ExtendedChecks1, cascades the legacy
list elements, then converts ExtendedChecks1 to ExtendedChecks2 when
cascading the type parameters. I end up with violations on
visitors[0].extended1 and visitors[0].extended2 . I don't see any
interpretation that seems to justify triggering the violation on the
Default group. The test points to spec section 5.1.3 but a reread of that
section does nothing for me here. Help would be appreciated here.
Next, can anyone explain the intent of @SpecAssertion#id() ?
Finally, this is the last TCK test I have failing, but next I have 928
tests being skipped. Our team has yet to figure out the mechanism by which
these tests are being skipped and we'd be glad for some help here as well.
Thanks all,
Matt and the Apache BVal team
6 years, 9 months
TCK expects tolerance of mismatched constraint and constraint validator
by Matt Benson
FrenchAddressListContainer defines @FrenchZipcodeListContainer as a
constraint that is validated by FrenchZipcodeConstraintValidator, but that
class declares its constraint type parameter as @FrenchZipCode. Because
that CV type does not override #init() this presumably works in the RI, and
the spec is a bit vague on this point, but the interface definition
describes type parameter A as "the annotation type handled by an
implementation." The spec section ConstraintValidator resolution algorithm
also correlates constraint A to the type parameters of the
ConstraintValidators described in the resolution rules. Finally, I don't
see anything under "What's new in 2.0" to indicate that this should be a
legal constraint definition.
Can I get a ruling? :)
Matt
6 years, 9 months
TCK expects constraint definition exception but specifies illegal method arguments first
by Matt Benson
InConstraintCompositionTest, tests
#testMixedConstraintTargetsInComposedAndComposingConstraintsCauseException()
and #testMixedConstraintTargetsInComposingConstraintsCauseException()
expect a ConstraintDefinitionException, but both attempt to validate an
empty Object array for a method whose signature is (int). However, the
methods of ExecutableValidator all declare that an IllegalArgumentException
will be thrown if any parameters to *those* methods do not match. I take
this to mean that a parameter array should be of the same length and
respectively assignable types to the parameter types supported by a method
or constructor, and similarly that a validated return value should actually
be a value that could have been returned by a given method or constructor.
I don't see that there is any specification as to when these
IllegalArgumentExceptions should be thrown, but it seems to me that you
would typically validate the objects you have locally before going off to
look up and validate the metadata for the appropriate bean type. I would
request that the parameter arrays used in these tests be updated to
something actually compatible with the methods in question, which could
only serve to further the emphasis on the actual spec item being verified
by the test method in question.
Thanks,
Matt
6 years, 9 months