11:50 a.m.
[
https://hibernate.onjira.com/browse/HV-509?page=com.atlassian.jira.plugin...
]
Hardy Ferentschik updated HV-509:
---------------------------------
Description:
If a bean is validated which has a collection-typed member annotated with {{@Valid}} and
of a type which itself has a class-level constraint, then the property paths of the
violations of that class-level constraint are wrong. The following shows an example:
{code:java}
public class FooTest {
@ValidFoo
private static class Foo {}
@Constraint(validatedBy = { ValidFooValidator.class })
@Target({ TYPE })
@Retention(RUNTIME)
public @interface ValidFoo {
String message() default "{ValidFoo.message}";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
public static class ValidFooValidator implements ConstraintValidator<ValidFoo,
Foo> {
public void initialize(ValidFoo annotation) {}
public boolean isValid(Foo foo, ConstraintValidatorContext context) {
return false;
}
}
private static class Bar {
@Valid
private List<Foo> foos = Arrays.asList(new Foo(), new Foo());
}
@Test
public void testBar() {
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Bar>> violations = validator.validate(new Bar());
//fails as pathes currently are "foos[1]", "foos[1]"
ConstraintViolationAssert.assertCorrectPropertyPaths(violations, "foos[0]",
"foos[1]");
}
}
{code}
The cause seems to be that the same {{PathImpl}} instance is used within both violations.
When the 2nd violation is created, the index of the shared {{PathImpl}} instance
originally created for the first violation is set from 0 to 1.
I think this can be circumvented by creating a copy of the path in the constructor of
{{ConstraintValidatorContextImpl}}.
Forum reference: https://forum.hibernate.org/viewtopic.php?f=9&t=1011952
was:
If a bean is validated which has a collection-typed member annotated with {{@Valid}} and
of a type which itself has a class-level constraint, then the property pathes of the
violations of that class-level constraint are wrong. The following shows an example:
{code:java}
public class FooTest {
@ValidFoo
private static class Foo {}
@Constraint(validatedBy = { ValidFooValidator.class })
@Target({ TYPE })
@Retention(RUNTIME)
public @interface ValidFoo {
String message() default "{ValidFoo.message}";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
public static class ValidFooValidator implements ConstraintValidator<ValidFoo,
Foo> {
public void initialize(ValidFoo annotation) {}
public boolean isValid(Foo foo, ConstraintValidatorContext context) {
return false;
}
}
private static class Bar {
@Valid
private List<Foo> foos = Arrays.asList(new Foo(), new Foo());
}
@Test
public void testBar() {
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Bar>> violations = validator.validate(new Bar());
//fails as pathes currently are "foos[1]", "foos[1]"
ConstraintViolationAssert.assertCorrectPropertyPaths(violations, "foos[0]",
"foos[1]");
}
}
{code}
The cause seems to be that the same {{PathImpl}} instance is used within both violations.
When the 2nd violation is created, the index of the shared {{PathImpl}} instance
originally created for the first violation is set from 0 to 1.
I think this can be circumvented by creating a copy of the path in the constructor of
{{ConstraintValidatorContextImpl}}.
Forum reference: https://forum.hibernate.org/viewtopic.php?f=9&t=1011952
Property path is wrong for cascaded validation of class-level
constraints
-------------------------------------------------------------------------
Key: HV-509
URL: https://hibernate.onjira.com/browse/HV-509
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Affects Versions: 4.2.0.Final
Reporter: Gunnar Morling
Assignee: Hardy Ferentschik
Fix For: 4.3.0.Alpha1
If a bean is validated which has a collection-typed member annotated with {{@Valid}} and
of a type which itself has a class-level constraint, then the property paths of the
violations of that class-level constraint are wrong. The following shows an example:
{code:java}
public class FooTest {
@ValidFoo
private static class Foo {}
@Constraint(validatedBy = { ValidFooValidator.class })
@Target({ TYPE })
@Retention(RUNTIME)
public @interface ValidFoo {
String message() default "{ValidFoo.message}";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
public static class ValidFooValidator implements ConstraintValidator<ValidFoo,
Foo> {
public void initialize(ValidFoo annotation) {}
public boolean isValid(Foo foo, ConstraintValidatorContext context) {
return false;
}
}
private static class Bar {
@Valid
private List<Foo> foos = Arrays.asList(new Foo(), new Foo());
}
@Test
public void testBar() {
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Bar>> violations = validator.validate(new
Bar());
//fails as pathes currently are "foos[1]", "foos[1]"
ConstraintViolationAssert.assertCorrectPropertyPaths(violations, "foos[0]",
"foos[1]");
}
}
{code}
The cause seems to be that the same {{PathImpl}} instance is used within both violations.
When the 2nd violation is created, the index of the shared {{PathImpl}} instance
originally created for the first violation is set from 0 to 1.
I think this can be circumvented by creating a copy of the path in the constructor of
{{ConstraintValidatorContextImpl}}.
Forum reference: https://forum.hibernate.org/viewtopic.php?f=9&t=1011952
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira