[bv-dev] BVAL-292 / BVAL-293 ConfigurationSource rename and behavior clarification

Hi all, I think it is time to wrap some of our latest discussion to be able to move on. Let's start with ConfigurationSource. Hopefully you remember that we discussed renaming it [1][2]. To make this more concrete I went ahead and already created a pull request for the API [3] and the spec [4]. I renamed ConfigurationSource to XMLConfiguration (as it already used to be called once) and stated in the configuration that Configuration#getXMLConfiguration returns the information from META-INF/validation.xml. It also specifies that Configuration#getXMLConfiguration never returns null, but rather the corresponding getters will return null respectively the empty set or map. Initially I thought about using DefaultConfiguration as an alternative name, but as Emmanuel pointed out in an earlier email it clashes to a certain degree with the programmatic Configuration interface. In the end I went back to XMLConfiguration especially after reading Gunnar's summary around this issue: {quote} AFAICS the original idea behind ConfigurationSource was to provide a way for BV integrators (e.g. CDI, or maybe an OSGi container etc.) to access the stuff from the BV default configuration (validation.xml) and make use of this when providing e.g. a validator in their specific environment. E.g. CDI might provide a CDI-enabled validator using the message interpolator from validation.xml. ConfigurationSource spares such integrators from having to parse validation.xml on their own. ConfigurationSource IMO shouldn't address any needs specific to an integration technology. So if for instance OSGi wanted to configure the constraint validator factory via the OSGi configuration service (a standard configuration API there), they would have to do that in the code integrating with BV (likely merging/delegating to the default configuration retrieved via ConfigurationSource). So the only scenario I can see where ConfigurationSource would represent something other than validation.xml, would be a BV provider which provides another means of default configuration. {quote} Regarding the last point, I don't see why for example Hibernate Validator should choose a different default configuration option than validation.xml. And if we would I would consider it a provider specific feature which does not have to be (indirectly) reflected in the spec. Thoughts? --Hardy Btw, Feel free to also comment on the pull requests as well. Hopefully we can come to an agreement within the next couple of days. [1] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-May/000389.html [2] http://lists.jboss.org/pipermail/beanvalidation-dev/2012-June/000390.html [3] https://github.com/beanvalidation/beanvalidation-api/pull/10 [4] https://github.com/beanvalidation/beanvalidation-spec/pull/8