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

[Hardy Ferentschik]

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