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

Gunnar, Agreed. Regards, Michael On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Agreed. Thanks Gunnar. On Tue, Feb 21, 2017 at 4:25 PM, Christian Kaltepoth <christian(a)kaltepoth.de&gt; wrote: > > Hey Gunnar, > > +1 for your proposal. I also think that this overriding scheme is > sufficient and covers all the real world use cases. > > Christian > > 2017-02-20 18:57 GMT+01:00 Michael Nascimento <misterm(a)gmail.com&gt;: >> >> Gunnar, >> >> Agreed. >> >> Regards, >> Michael >> >> On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev