[
https://issues.apache.org/jira/browse/BVAL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968489#action_12968489
]
Chris Ey commented on BVAL-88:
------------------------------
If you have any question regarding my fix feel free to comment here (I'm
watching this bug).
The gist of it is, that if we are in "reportAsSingleViolation" mode, and
already found a violation while in this mode, we should not add another
composed violation on top of it.
This condition is reached when a validated bean has a violation on one of its
properties, and there also is a child bean which may or may not have a
violation by itself.
The error is: It will always add a violation for the child bean, whether or not
it has an actual violation. My patch fixes this and all tests pass.
> Cascaded validation adds a constraint violation for valid child property
> ------------------------------------------------------------------------
>
> Key: BVAL-88
> URL: https://issues.apache.org/jira/browse/BVAL-88
> Project: BeanValidation
> Issue Type: Bug
> Affects Versions: 0.2-incubating
> Reporter: Chris Ey
> Attachments: BVAL-88.patch
>
>
> Precondition:
> Parent bean (call it 'Department') has an invalid property, say,
> "description" annotated with @NotEmpty and value is null.
> Department also has a valid child element, say, Person manager, which itself
> has a name. Manager is annotated with @Valid and @NotNull, and name is
> annotated with @NotEmpty. Both manager and name are correctly populated with
> non null values:
> Department {
> @NotEmpty
> String description;
> @NotNull;
> @Valid
> Person manager;
> }
> Person {
> @NotEmpty
> String name;
> }
> Values:
> Department.description: Intentionally left empty (to cause a constraint
> violation)
> Department.manager: new Person()
> Person.name: "Valid Value"
> Action:
> Department is validated using bean validation.
> Expected:
> 1 Constraint violation:
> empty Department.description
> Actual:
> 2 Constraint violations:
> empty Department.description
> empty Person.name
> I debugged a bit and it seems like when traversing down to Person's
> properties, it somehow switches into (isReportsAsSingleViolation() == true)
> path (constraintviolation.j...@162), then it sets failed = true in line 171,
> because the context does have violations (caused previously by
> Department.description). But failed should apparently stay false, because
> there was no /new/ error caused by Person.
> Nevertheless, a new ConstraintViolation gets added in line 183 because failed
> was true (while it shouldn't be).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
