bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: guice module structure
Date Wed, 21 Mar 2012 20:47:09 GMT
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


On Wed, Mar 21, 2012 at 3:41 PM, Simone Tripodi
<> 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
> On Tue, Mar 20, 2012 at 7:27 PM, Matt Benson <> 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

View raw message