[bv-dev] BVAL-265 exposing data in validation.xml

[Emmanuel Bernard]

I've called it 

    ConfigurationSource getConfigurationSource();

I am not 100% happy as it's fairly abstract but that's the best I came up with

On 14 févr. 2012, at 20:55, Gunnar Morling wrote:

> I've wondered the same, too. I couldn't find a good alternative,
> though, do you have something particular in mind? On the other hand
> the question also is, how likely is it that we will add other means of
> external configuration?
> 
> --Gunnar
> 
> 2012/2/14 Sebastian Thomschke <sebastian.thomschke at web.de>:
>> I'd also go for option 2. The question for me is however, is it
>> necessary to have the word XML in the method name? I mean could the
>> potential configuration source be a different one in the future, e.g. a
>> property file, a system property, some other non-XML config source.
>> 
>> Seb
>> 
>> On 13.02.2012 22:51, Gunnar Morling wrote:
>>> Hi,
>>> 
>>> I also favor option #2.
>>> 
>>> How would you like a dedicated configuration object representing the XML config:
>>> 
>>> Configuration conf = Validation.byDefaultProvider().configure();
>>> XmlConfiguration xmlConf = conf.getXmlConfiguration();
>>> 
>>> String cvfClassName = xmlConf != null ?
>>> xmlConf.getConstraintValidatorFactory() : null;
>>> 
>>> if( cvfClassName == null ) {
>>>       ...
>>> }
>>> 
>>> This would limit the number of potential new methods on Configuration
>>> and also allow for a quick check whether an XML config exists at all.
>>> 
>>> --Gunnar
>>> 
>>> 
>>> 2012/2/13 Emmanuel Bernard<emmanuel at hibernate.org>:
>>>> Hi,
>>>> I'd love your quick feedback on http://beanvalidation.org/proposals/BVAL-265/ which is in the way of solving the dependency injection proposal.
>>>> 
>>>> I am copying the content here for convenience.
>>>> 
>>>> ---
>>>> # Expose settings defined in XML in the Configuration API (for ConstraintValidatorFactory, MessageInterpolator etc)
>>>> 
>>>> [Link to JIRA](https://hibernate.onjira.com/browse/BVAL-265)
>>>> 
>>>> ## Goals
>>>> 
>>>> While working on the dependency injection (BVAL-238), I need to solve a subproblem. A container needs to know what is in `validation.xml`
>>>> to either:
>>>> 
>>>> - plug its `ConstraintValidatorFactory` / `MessageResolver` etc implementation,
>>>> - use the one defined by the user and possibly instantiate these objects as managed objects
>>>> 
>>>> There are a few strategies
>>>> 
>>>> ## Option 1: Let the XML parsing be done by the DI bootstrap code
>>>> 
>>>> The easiest solution is to leave the container read `validation.xml` and extract information itself. No need to change the API in this case.
>>>> 
>>>> ## Option 2: Expose the data on the `Configuration` object as strings
>>>> 
>>>> Add three methods to `Configuration` to return the explicit value (if set) and null otherwise:
>>>> 
>>>> - `String getConstraintValidatorFactoryFromXML()`
>>>> - `String getMessageInterpolatorFromXML()`
>>>> - `String getTraversableResolverFromXML()`
>>>> 
>>>>         //example of bootstrap code by the container
>>>>         Configuration conf = Validation
>>>>             .byDefaultProvider()
>>>>             .configure();
>>>> 
>>>>         String cVFClassName = conf.getConstraintValidatorFactoryFromXML();
>>>>         ConstraintValidatorFactory cVF;
>>>>         if (cVFClassName == null) {
>>>>            //use DI custom one
>>>>            cVF = new ContainerCustomConstraintValidatorFactory();
>>>>         }
>>>>         else {
>>>>            cVF = Container.getManagedBean(cVFClassName);
>>>>         }
>>>> 
>>>>         //same logic for MessageResolver and TraversableResolver
>>>>         [...]
>>>> 
>>>>         conf.constraintValidatorFactory(cVF)
>>>>            .messageResolver(messageRes)
>>>>            .traversableResolver(traversRes)
>>>>            .buildValidatorFactory();
>>>> 
>>>> 
>>>> The spec would recommend that `getConstraintValidatorFactoryFromXML()` and its siblings lazily read the XML file.
>>>> 
>>>> ## Option 3: Expose the data in `Configuration` as instantiated objects
>>>> 
>>>> Same as above except that `Configuration` returns already instantiated objects. But I don't think that's an
>>>> interesting option.
>>>> 
>>>> ## Discussion
>>>> 
>>>> Which options should be favor? I am tempted by option 2 but the risk is an explosion of `getDefaultXXX()`
>>>> and `getXXXFromXML()` the more we add components to Bean Validation.
>>>> 
>>>> What do you think?
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev