[bv-dev] BVAL-265 - Expose settings defined in XML in the Configuration API

[Matt Benson]

Hi all,
  Sorry for my extreme tardiness in doing the backing research on this
issue.  I am fine with the standing changes, so far as they go;
however it seems like this could also be an opportunity of sorts.  If
the Configuration object is going to expose the ConfigurationSource
(and thereby the data corresponding to that mined from the XML
configuration), it would seem to move the responsibility of parsing
the XML and eliminate the need for
ConfigurationState#getMappingStreams().  This method is AFAICT the
place that complicates the building of multiple ValidatorFactory
instances from a single Configuration, which was the subject of a
thread which I cannot currently find, but whose participants I recall
as having included Gunnar and myself.

Matt

On Wed, Jun 13, 2012 at 6:04 AM, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On Jun 12, 2012, at 10:50 PM, Gunnar Morling wrote:
>
>> Any preferences or other suggestions?
>
> To take up my original questions again w/ my thoughts around it
>
> * 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"?
>
> Apparently the "typically" comes from the idea that the configuration source could be different one (e.g. property file) for some
> providers. IMO this is a provider specific feature. The specification uses validation.xml for these bootstrap parameters and that's
> what the specification should be concerned about. How can I guarantee portable applications if Configuration#getConfigurationSource
> does not returns the same values between different providers?
>
> * What do I return if there is no validation.xml? null? Or the class names of the implementations default implementations?
>
> I think there should be an ConfigurationSource (or whatever we are going to call it) instance returned, but the getters return 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.
>
> BootstrapConfiguration, DefaultConfiguration, ValidationXmlConfiguration (assuming that we are really only dealing w/ validation.xml)
>
> --Hardy
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev