[bv-dev] Value extraction open issue #5: Should value extractors be discoverable via the service loader?

[Gunnar Morling]

Hi,

I think there already was agreement essentially that value extractors
should be discoverable using the service loader mechanism.

This will allow providers of custom collection types (e.g. Google
Guava) to bundle a value extractor with their library and have it
being picked up automatically, allowing application developer to put
@Valid to these types without any further configuration.

So I've prepared a change for that:

    https://github.com/beanvalidation/beanvalidation-spec/pull/140

The open question was how value extractors should be
overridden/disabled. I've foreseen the following sources for value
extractors, in descending order of precedence:

* ValidatorContext#addValueExtractor(ValueExtractor<?>)
* Configuration#addValueExtractor(ValueExtractor<?>)
* META-INF/validation.xml
* META-INF/services/javax.validation.valueextraction.ValueExtractor

If an extractor for a specific type (e.g. java.util.List) and type
parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
will override any extractors for the same type and type parameter
given at the lower levels and the built-in extractor for that type and
type parameter, if any.

I don't think there's a way needed to explicitly disable an extractor
without providing an alternative implementation. I.e. I cannot see a
use case why one would want to disable cascaded validation let's say
for List. Hence the proposed overriding scheme.

Can you please let me know what you think of this by the end of the week?

Thanks,

--Gunnar