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

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