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

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