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

[Hardy Ferentschik]

I think a wrapper object for the xml configuration is a good idea. 
I was wondering how the actual loading of the xml files is supposed to work? Just via the (context) class loader?
Or is there a need for a Loader interface which allows other strategies?

--Hardy

On Feb 14, 2012, at 1:10 AM, Emmanuel Bernard wrote:

> 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
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev