Test case - https://github.com/hibernate/hibernate-test-case-templates/pull/26
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 h3 . Node hash code does not consider path
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 h3 . 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 getting replaced with custom constrain and marked as processed (and so on)...
The bean is never returned as processed for default group.
It is possible to workaround issue by re-arranging groups.
{code:java}
@GroupSequence({ Magic.class,YourAnnotatedBean.class})
public class YourAnnotatedBean { ... }
{code} |
|
