[
https://issues.apache.org/jira/browse/BVAL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Ey updated BVAL-88:
-------------------------
Attachment: BVAL-88-unittest-cey.patch
This patch contains a unit test to reproduce the problem.
Writing this test, I learned more about the problem: It was cause by the
NotEmpty annotation we still used from hibernate validation. While we can and
will switch to Apache Bean Validation's NotEmpty annotation, Hibernate's is
written with Javax annotations only and therefore should be implementation
independent.
I included Hibernate's NotEmpty annotation to the test source to show the
problem. After applying my other patch, this problem is fixed and the test
passes.
> 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
> Assignee: Donald Woods
> Fix For: 0.3-incubating
>
> Attachments: BVAL-88-unittest-cey.patch, BVAL-88.patch,
> BVAL-88drw.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.
