It is possible to cause stack overflow with custom groups sequence for beans with circular reference.
As seen in my test case (below) validation of object graph with a loop might blow the stack.
Supposedly, there are two reasons:
1. NodeImpl stopped using [parent hash|https://github.com/hibernate/hibernate-validator/commit/7546a0c14bd70d6c4b707cb9bc4d333a87891148#diff-ec06ef14de55635f374c64ab50ac8405] in its own hash code (jira: HV-1480, [PR#845|https://github.com/hibernate/hibernate-validator/pull/845]) .
This forced [CachingTraversableResolverForSingleValidation|https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/resolver/CachingTraversableResolverForSingleValidation.java] to return false-positive for node in a loop.
For my test case it causes *traversables* to return cached object regardless of actual path in object (pathToTraversableObject.toString() - bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean)
2. Ordering of groups plays decisive role.
Custom groups enables *ValidatorImpl.validateConstraintsForDefaultGroup()* to override group sequence and if default group is not last in this list, it causes *validationContext.markCurrentBeanAsProcessed( valueContext )* to mark wrong group in *processedGroupUnits*. When it cascades to next level with default group, which is role getting replaced with custom constrain and marked as processed (and so on) . ..
It is possible to workaround issue by re-arranging groups.
{code:java}
@GroupSequence({ Magic.class,YourAnnotatedBean.class})
public class YourAnnotatedBean { ... }
{code}
Tet case - https://github.com/hibernate/hibernate-test-case-templates/pull/26 |
|
