You can find the discussion around the original proposal back from February at
Can someone point me to the initial discussion around the original
ConfigurationSource changes? I have some concerns but I'd like to be
able to study up to be sure I understand the decisions that were made
(despite this thread's implying that the changes aren't set in stone).
On Tue, Jun 12, 2012 at 3:50 PM, Gunnar Morling <firstname.lastname@example.org> wrote:
> Any preferences or other suggestions?
> 2012/6/2 Gunnar Morling <email@example.com>:
>> 2012/6/1 Emmanuel Bernard <firstname.lastname@example.org>:
>>> We can also imagine a specific provider offering an alternative source of configuration and using this interface to expose it.
>>> That was the rational behind the use of "typically".
>> Maybe some bits of explantation would make it clearer?
>> "Return information retrieved from the user-provided default
>> configuration. While loaded from the <i>META-INF/validation.xml</i>
>> file by default, implementations are free to provide other means of
>> default configuration such as a properties file."
>>>> * What do I return if there is no validation.xml? null? Or the class names of the implementations default implementations?
>>> Good question, I'm in favor of null. anyone against that?
>> +1 for returning null.
>>>> * Last but not least, why ConfigurationSource?
>>> Technically this is the configuration but we already have a programmatic Configuration object.
>>> - XmlConfiguration
>>> - StaticConfiguration
>>> - ConfigurationSource
>>> - ConfigurationParameters
>>> - ?
>> Some more ideas:
>> - DefaultConfiguration
>> - UserDefaultConfiguration
>> - ExternalConfiguration
>> - BootstrapConfiguration
>> I find the term "source" a bit mis-leading, as I would regard
>> something like "XML" or "properties file" as source, but the returned
>> object from that source as "configuration". I think I'm preferring
>> (User)DefaultConfiguration, as it IMO clearly describes the object's
>> I've created BVAL-293  for any clarifications/refinements around
>>  https://hibernate.onjira.com/browse/BVAL-293
> beanvalidation-dev mailing list
beanvalidation-dev mailing list