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

Emmanuel Bernard emmanuel at hibernate.org
Mon Feb 20 12:04:05 EST 2017

There is always the option to remove / not put @Valid and other
@Constraint annotations if one does not want an extractor to be used.
So I'm aligned with your proposal.

On Mon 17-02-20 16:54, Gunnar Morling wrote:
>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?
>beanvalidation-dev mailing list
>beanvalidation-dev at lists.jboss.org

More information about the beanvalidation-dev mailing list