Gunnar,

Agreed.

Regards,

Michael

On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar@hibernate.org> wrote:

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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev