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
