bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: guice module structure
Date Wed, 21 Mar 2012 20:41:17 GMT
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 <gudnabrsam@gmail.com> 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

Mime
View raw message