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

[Hardy Ferentschik]

On Jul 17, 2012, at 10:42 PM, Gunnar Morling wrote:

>> 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.
> 
> But does it really clash? IMO Configuration provides a unified way for
> accessing the effective configuration. It allows to change the
> configuration in a programmatic way but it could also provide a handle
> to the default configuration from validation.xml via
> getDefaultConfiguration().
> 
> I see there is a clash with getDefaultMessageInterpolator() etc,
> though (which returns the default implementations as demanded by the
> spec.), so maybe the method returning the user provided default
> configuration should be named getExternalDefaultConfiguration(),
> getBootstrapDefaultConfiguration() or similar.

That's exactly the clash I am talking about. If we call it _DefaultConfiguration_ and just call the getter
Configuration#getDefaultConfiguration we have for example Configuration#getDefaultMessageInterpolator, but
also Configuration#getDefaultConfiguration()#getMessageInterpolatorClassName. IMO that can be misleading.

One way to avoid this would be to call the accessor #getExternalDefaultConfiguration() or #getBootstrapDefaultConfiguration()
as you suggest, but then I rather call it BootstrapConfiguration to begin with. 

I chose XMLConfiguration, because I think it is ok to limit this method to validation.xml. If we really want to keep 
"doors open" I could imagine renaming to BootstrapConfiguration. 

What do others think?

--Hardy