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

[Emmanuel Bernard]

Ahah, great minds think alike. I have had the exact same thought this evening. This is much cleaner and future proof. Maybe replacing XML with static in the name. 

On 13 févr. 2012, at 22:51, Gunnar Morling <gunnar.morling at googlemail.com> 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