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

[Marco Molteni]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170222/0cb320eb/attachment-0001.html