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

[Emmanuel Bernard]

That's a good point but it's a problem we already have to solve as Configuration implementations already parse the XMl file, albeilt a bit later. 

Kevin is working on the OSGi proposal which I think will shred some lights here.

On 14 févr. 2012, at 09:43, Hardy Ferentschik wrote:

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