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