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

[Gunnar Morling]

As there's agreement on this approach in general, I've moved forward
and filed a PR with the API change:

    https://github.com/beanvalidation/beanvalidation-api/pull/89

Feedback welcome!

--Gunnar


2017-02-22 22:32 GMT+01:00 Marco Molteni <moltenma at gmail.com>:
> Agreed. Thanks Gunnar.
>
> On Tue, Feb 21, 2017 at 4:25 PM, Christian Kaltepoth
> <christian at kaltepoth.de> 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 at gmail.com>:
>>>
>>> Gunnar,
>>>
>>> Agreed.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Feb 20, 2017 at 12:54 PM, Gunnar Morling <gunnar at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev