3:51 p.m.
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