[bv-dev] Value extraction open issue #5: Should value extractors be discoverable via the service loader?
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:
>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:
>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