I didn’t really know what I should have added as a node name so I just guessed nothing.

Built-in value extractors section in the spec describes the names used for built-in extractors. While you are not required to pass a name … Hibernate Validator logic around nodes and paths was built with the idea in mind that those iterable (multivalued) containers would have something as a container element.

That’s why if you do not pass anything as a node name, it messes up not only the paths in the constraint violations but also provides unexpected results when you call isInIterable() / getIndex() …

The string for that node comes out as expected: componentValidatorText[0], but I expected that isInIterable() would return true and that getIndex()would return 0. But, they do not.

as for this part … there’s a bit of explanation in the Javadocs. You can also take a look at the Listing 6.4 of ConstraintViolation section. In short - both isInIterable() / getIndex() are intended for a container element and not for the container itself. So if you have a path like componentValidatorText[0].<some container element name> then <some container element name> node will return isInIterable() == true / getIndex() == 0 but node componentValidatorText[0] will be just considered a container so it is not in iterable and as a result doesn’t have an index – isInIterable() == false / getIndex() == null

Thank you for your help! Adding the nodeName fixes this issue. I didn’t really know what I should have added as a node name so I just guessed nothing.

I have a related question for you though. It has to do with the PropertyNode in the path returned by constraintViolation.getPropertyPath(). The string for that node comes out as expected: componentValidatorText[0], but I expected that isInIterable() would return true and that getIndex()would return 0. But, they do not. They return false and null instead. My question is why is that? If there is a RTFM somewhere that I need to look at, just let me know. TIA

Hey @Jay Gorrell thanks for reporting the issue and providing the reproducibles. The Path implementation deliberately is not creating deep copies for performance and resource usage reasons. While that’s so, there’s a problem you’ve reported. It comes from the fact that you are passing a null value as a nodeName into receiver.indexedValue(..). This results in a created path missing a container element node; you can see that by inspecting the nodes in the path or by calling a Node#getIndex() either on the node or nodeImpl in your test case.

If you'd like to make it work on with the version of the validator you are using right now – you’d have to pass a nonnull node name. Keep in mind that that will change the string representation of the path (that’s if you care about how it looks).

In the meantime, I’ll submit a patch that should address the problem.