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

[Sebastian Thomschke]

I don't have anything particular in mind. It just bothers me that the 
configuration source type should be hard coded in a java method name.
For the DI framework the type of the config source should not matter.

Seb

On 14.02.2012 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