[bv-dev] BVAL-265 - Expose settings defined in XML in the Configuration API

Gunnar Morling gunnar at hibernate.org
Sat Jun 2 06:25:03 EDT 2012


2012/6/1 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 31 mai 2012, at 14:35, Hardy Ferentschik wrote:
>>
>> * How do I interpret "typically the "META-INF/validation.xml file" - typically implies an alternative. Is there is one how do I
>>   differentiate between these alternatives? Shouldn't the docs read "Return information stored in META-INF/validation.xml"?
>
> When we discussed the feature, Sebastian mentioned
>
>> I mean could the potential configuration source be a different one in the future, e.g. a
>> property file, a system property, some other non-XML config source.
>
> This triggered the move away from XMLConfiguration to ConfigurationSource.
> 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? If I look at the class I see configuration parameters so why not call this
>>   (ValidationXml)ConfigurationParamters or (ValidationXml)BootstrapParameters. "Source" implies for me that I can get information about
>>   how the configuration was provided, e.g. XML vs programmatic.
>
> I am not a big fan of ConfigurationSource either but that was the best we came up with. We had XMLConfiguration before.  I think I also proposed StaticConfiguration at some point.
> I'm not sure ConfigurationParameters is truly accurate though. This interface represents the content you retrieve from validation.xml today.
> Is that merely parameters?
> Technically this is the configuration but we already have a programmatic Configuration object.
>
> Ideas?
>
> - 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
intention.

I've created BVAL-293 [1] for any clarifications/refinements around
ConfigurationSource.

--Gunnar

[1] https://hibernate.onjira.com/browse/BVAL-293


> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



More information about the beanvalidation-dev mailing list