You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by Matt Benson <gu...@gmail.com> on 2012/03/20 19:27:04 UTC
guice module structure
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
Re: guice module structure
Posted by Matt Benson <gu...@gmail.com>.
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
<si...@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 <gu...@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
Re: guice module structure
Posted by Simone Tripodi <si...@apache.org>.
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 <gu...@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