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

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

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&lt;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

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