5:25 a.m.
2012/6/1 Emmanuel Bernard <emmanuel(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev