[
http://opensource.atlassian.com/projects/hibernate/browse/HV-433?page=com...
]
Gunnar Morling commented on HV-433:
-----------------------------------
Christian, could you provide a minimal test case demonstrating this problem? I ran the
following test which reflects the situation as I understood it but it runs successfully:
{code:java}
public class Hv433 {
private static class Bar {
@NotNull
private String string;
}
private static class Foo {
@Valid
protected Bar bar;
}
private static class Baz extends Foo {
}
@Test
public void hv433() {
Baz baz = new Baz();
baz.bar = new Bar();
Set<ConstraintViolation<Baz>> violations =
Validation.buildDefaultValidatorFactory().getValidator().validate(baz);
assertEquals(violations.size(), 1);
assertEquals(violations.iterator().next().getMessage(), "may not be null");
assertEquals(violations.iterator().next().getPropertyPath().toString(),
"bar.string");
}
}
{code}
You are mentioning XML and programmatic constraint configuration. Is there such a
configuration for your base type (here Foo)?
Cascaded validation on superclass fields does not work if only @valid
is used
-----------------------------------------------------------------------------
Key: HV-433
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-433
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.1.0.Final
Environment: Java 1.5.0 (IBM J9 2.3); Hibernate Validator 4.1.0.FINAL
Reporter: Christian Quanz
Cascaded fields are not validated if the following applies:
- Only @valid is specified for a particular field, no further constraints
- Validation takes place on an object of a sublcass of the class where the field to be
validated is defined
Simply no validation will take place on the object assigned to the field. Eyerything
works fine if I add another constraint definition, e.g., @NotNull to the field, as in the
examples in the documentation. If I validate an object of the class where the field is
defined, it also works. I doubt that it matters, but the field's visibility is
"protected".
I tested it for XML constraint definitions and programmatic constraint definitions.
I could trace the error back to BeanMetaDataImpl->initFieldConstraints(...), where the
flag cachedFieldIsCascaded will be false. Thus, addCascadedMember(...) will not be called
for the field.
In case of any additional constraint being defined, the flag cachedFieldIsCascaded will
be true.
Hope that helps.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira