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

[Gunnar Morling]

Hi Hardy,

thanks for this great summary.

> I renamed ConfigurationSource to XMLConfiguration

I've added some comments regarding the naming to the pull request. Summary:

* I think names should be based on semantics instead of technical
aspects. So the name should express what concept is modeled here and
not how it is realized. Therefore I'd prefer DefaultConfiguration
(because that's basically what this class is about, it represents the
BV default configuration provided by the user), or maybe something
like BootstrapConfiguration. The fact that the default configuration
is realized in form of an XML file, is not really relevant for the
user of this type, so it shouldn't shine through in the name IMO.
* Not having "XML" in the name leaves the door open for other
potential kinds of default configuration in the future. Although I
think we agree that this is not really likely, I'd still prefer to
enable such an evolvement without having to rename things then.

> Regarding the last point, I don't see why for example Hibernate Validator should choose a different default configuration option than validation.xml.

+1 I also don't see really a reason for that.

> And if we would I would consider it a provider specific feature which does not have to be (indirectly) reflected in the spec.

The thing is, if a BV provider would implement some other means of
default configuration via a provider-specific API, this would also
require BV integrators to know this API and to chose which kind of
default configuration to retrieve, the standard one or the
provider-specific one. Thinking about standardized integrators such as
CDI or JSF, this seems not really feasible.

So if we want to pave the way for other future kinds of default
configuration, this would have to be exposed via a standardized API,
that is, via Configuration#get<NAME_TBD>(). BV providers could then
return an implementation of the default configuration based on their
alternative configuration approach, without BV integrators having to
act any differently. I don't think that's likely, but leaving the door
open for this by using a somewhat more generic name seems like a good
trade-off to me.

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

--Gunnar


2012/7/16 Hardy Ferentschik <hardy at hibernate.org>:
> 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
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev