bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
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
there.

Thanks,
Matt

On Wed, Mar 21, 2012 at 3:41 PM, Simone Tripodi
<simonetripodi@apache.org> 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 <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