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

[Emmanuel Bernard]

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".

> 
> * 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?

> 
> * 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
- ?