bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: graduating the guice integration from sandbox
Date Mon, 10 May 2010 08:17:23 GMT
Hola Carlos,
thank you very VERY much, very *interesting* hints!!!

Just to be clear with everybody and to explain better what the guice
module is for:
* bootstrap bval using guice;
* obtain ConstraintValidator instances using the guice injector, so to
easily support the DI;
* easily inject the Validator reference into components that require it;
* easily intercept methods and validate method arguments.

BTW as you noticed there are a lot of points that can be improved: I
like both the approaches, the one you wrote on your blog is *very*
interesting and I'll take a deep look on ASAP, at the same time the
@Valid it's not so bad IMHO.
Also adding the return method validation support is very very fine,
easy to add in the existing code but at the same time provides an
excellent feature.

Once again, thanks a lot for your hints, hope to see you as committer soon!!! :)
Cuidate, un fuerte abrazo,

On Mon, May 10, 2010 at 12:10 AM, Carlos Vara <> wrote:
> Hi Simone,
> I took a look at the code, very good work there!
> I'm afraid I can't comment much about the guice part as I'm more of a spring
> man myself, but I can comment a little on the validation part.
> First, just to check that I understood what it does right:
> - It creates an interceptor for method calls annotated with @Validate and
> validates all the arguments. In case any validation error is found, it
> throws a CVE.
> If the above is right, a few pointers on the validation part:
> - If you validate the arguments individually, maybe having an extra
> annotation in them can help improve the speed of the code. Take care that
> calling validator.validate(..) for all basic types (Strings, Integers, etc.)
> will always output an empty set, and those arguments are very common.
> You can use @Valid as a marker for the arguments that you want to validate,
> this way, a validated method call would be like this:
> @Validate
> public String myMethod(String notValidated, @Valid Person validatedPerson) {
> ... }
> You may decide to validate all arguments in case @Validate is present and no
> argument is annotated with @Valid.
> - Although it is not portable, you may also want to take a look at the
> method validation API that the Apache implementation has. It works quite
> well in this scenario. I posted a quick implementation I did with AspectJ
> here:
> If you are interested, you could do a second interceptor that takes
> advantage of it in case the JSR-303 implementation is the apache one.
> - One last thing, in ValidateMethodInterceptor.invoke(), you may want to
> also validate the return value before returning.
> Oh, and my non-binding opinion about moving it out of the sandbox would be a
> yes. All the above comments are just possible improvements, IMHO code uses
> the validation API correctly to solve an interesting problem.
> Regards,
> Carlos
> On Sat, May 8, 2010 at 1:07 PM, Simone Tripodi <>wrote:
>> Hi all guys,
>> I'd like to ask you what you think about moving the actual google
>> guice integration support from sandbox to current modules.
>> I just integrated the groups support in the AOP interceptor and it
>> seems working nicely, at least for me, I'd really would like if
>> someone could provide feedbacks.
>> Every kind of help will be more than appreciated, thanks in advance!
>> Simo

View raw message