[bv-dev] Value extraction open issue #5: Should value extractors be discoverable via the service loader?
moltenma at gmail.com
Wed Feb 22 16:32:52 EST 2017
Agreed. Thanks Gunnar.
On Tue, Feb 21, 2017 at 4:25 PM, Christian Kaltepoth <christian at kaltepoth.de
> Hey Gunnar,
> +1 for your proposal. I also think that this overriding scheme is
> sufficient and covers all the real world use cases.
> 2017-02-20 18:57 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
>> On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar at hibernate.org>
>>> 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:
>>> * 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
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the beanvalidation-dev