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

Sebastian Thomschke sebastian.thomschke at web.de
Tue Feb 14 08:21:38 EST 2012


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



More information about the beanvalidation-dev mailing list