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

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(a)googlemail.com&gt; 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&gt;: >> 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