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

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev