Hi, Simo. The method validation reasoning makes sense. Even still I think we can avoid coding to BVal's ConfigurationImpl; I am currently considering breaking our implementation of ConfigurationState out of our ConfigurationImpl class, which is what made me begin considering this topic at all (well, that and the fact that I think ConfigurationImpl's constructors might also be good candidates for refactoring). It doesn't sound like the changes I am proposing would be harmful, so I'll simply not break any unit tests and we'll go from there.
Thanks, Matt On Wed, Mar 21, 2012 at 3:41 PM, Simone Tripodi <[email protected]> wrote: > Hi Matt, > thanks a lot for your valuable review! > > The simple reason why I bound the o.a.bval.* classes is that when I > started implementing the module for Guice, I intended build an > integration module for the Apache Bval implementation only (not pure > JSR303) :P > > Indeed, the ConfigurationStateProvider return an instance of > org.apache.bval.jsr303.ConfigurationImpl. > > Moving to a pure JSR303 APIs implementation would make of course the > guice module more usable also by other BeanValidation vendors, but our > version was the only one at the time of coding on supporting the > MethodValidator - which interceptor is turned on by default in the > ValidationModule... so no reason why to support 3rd party > implementations... > > Thoughts? > > Thanks a lot in advance, all the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Tue, Mar 20, 2012 at 7:27 PM, Matt Benson <[email protected]> wrote: >> Hi all, >> Doing an informal audit of BVal code, and I notice that the guice >> module's structure is such that the ValidatorFactoryProvider relies on >> an instance of ConfigurationState injected by the >> ConfigurationStateProvider. It isn't explicitly defined in the >> specification how ConfigurationState instances are obtained, however, >> and so our CSP must directly instantiate BVal's ConfigurationImpl >> which implements both Configuration and ConfigurationState. It would >> seem that if we instead injected the Configuration, the VFP could then >> simply call Configuration#buildValidatorFactory resulting in a guice >> module that should work across bean validation implementations. >> >> Am I missing anything here? >> >> Matt
