Fix adaptation of violations on Set method parameter

[snussbaumer]

Since commit 8552e14, validation of Set values (for example Set<@NotBlank String>) crashes with error : No way to unwrap Iterable without index

With this fix we don't know which value exactly is the problem, but at least we have a working validation

Maybe there is a way to know exactly which value(s) are the culprit, but without an index I don't know how to find it.

Or maybe there is a better way to fix the problem, I trust you'll do a thorough review and find it, I'm not that familiar with the codebase 😄 .

Thanks

This is the error without the fix :

java.lang.IllegalStateException: No way to unwrap Iterable without index
	at org.springframework.util.Assert.state(Assert.java:78)
	at org.springframework.validation.beanvalidation.MethodValidationAdapter.adaptViolations(MethodValidationAdapter.java:358)
	at org.springframework.validation.beanvalidation.MethodValidationAdapter.validateArguments(MethodValidationAdapter.java:247)
	at org.springframework.validation.beanvalidation.MethodValidationAdapterTests.testArgs(MethodValidationAdapterTests.java:237)
	at org.springframework.validation.beanvalidation.MethodValidationAdapterTests.validateValueSetArgument(MethodValidationAdapterTests.java:223)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

[snussbaumer]

I the fix could then be backported to 6.1.x that would be great

[rstoyanchev]

There is an underlying limitation in that there is no way to access the value in the Set that caused the violation (see jakartaee/validation#194).

Initially, we used to create a ParameterErrors instance for arrays and collections, with the collection/array as the backing object, and the container + container index allowing you to access the value. It sort of worked for Set but there was no index and no way to access the actual value. There was an attempt to improve that in #31530 for Set and other (custom) container types, but it was based on an incomplete understanding of the available metadata, leading to #31746 and the subsequent change d7ce13c is what made it impossible to use a collection that is not indexed.

The subsequent change 8552e14 that you referenced further refined that so that collections/arrays are more correctly represented with ParameterValidationResult as directly validated method parameters (rather than with ParameterErrors for cascaded violations on an Object), so there is no longer a backing object to set, just the argument value. That did not change anything for sets though.

I think we could create ParameterValidationResult with the Set as the value that was validated, rather than the actual element, which we cannot access, but there would be no container and no container index. That would allow the error to be reported as before, but if there are multiple errors on the same Set there would be no way of telling which one is which. This wouldn't be anything new, but would simply restore what was possible in 6.1.2.