Let's assume the following code:
{code:java}
public class TestX {
@Valid
public TestY emb1;
public TestY emb2; // no @Valid annotation
public TestX(TestY emb1, TestY emb2) {
this.emb1 = emb1;
this.emb2 = emb2;
}
}
public class TestY {
@Max(3)
@Min(value = 2, groups = OnUpdate.class)
public int i2;
private TestY(int i2) {
this.i2 = i2;
}
}
{code}
And the following validation checks:
{code :java }
TestX foo = new TestX(new TestY(2), new TestY(3));
Validator validator = ...;
Set<ConstraintViolation<TestX>> s1 = validator.validateProperty(foo, "emb1.i2", Default.class);
Set<ConstraintViolation<TestX>> s2 = validator.validateProperty(foo, "emb2.i2", Default.class);
{/code}
These checks completed successfully, returning two sets, in HV 4.1.0. However, in HV 5.4.1, the second call throws an exception:
{noformat}
java.lang.IllegalArgumentException: HV000039: Invalid property path. Either there is no property emb2.i2 in entity TestX or it is not possible to cascade to the property.
at org.hibernate.validator.internal.engine.ValidatorImpl.collectMetaConstraintsForPathWithValue(ValidatorImpl.java:1473)
at org.hibernate.validator.internal.engine.ValidatorImpl.validatePropertyInContext(ValidatorImpl.java:801)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateProperty(ValidatorImpl.java:222)
{noformat}
I checked the source code and it turns out, that the new implementation checks, whether the given property is cascading, before entering it (and throws the exception), whereas the implementation from HV 4.x - does not.
The migration guides do not mention any change in this place. The documentations for both HV 4.x and 5.x say that "@Valid" annotation is not honored by validateProperty() (section 2.2.2.3), which is not consistent with the actual behavior. Both Bean Validation 1.0 and 1.1 say nothing that honoring @Valid annotation, but my experience with the specification is not big enough to make a clear conclusion here.
So this may be a violation of the specification (where the appropriate code change shall be made to fix it), or a regression with two possible solutions:
# reverting to the original behavior from HV 4.x,
# or updating the confusing note in the documentation. |
|
