[bv-dev] Triggering method validation

Gunnar Morling gunnar.morling at googlemail.com
Sun Jan 22 14:33:27 EST 2012


Hi experts,

I'm in the middle of writing a proposal document for BVAL-241 (method
validation), which I'm planning to put up for discussion within the
next days.

One item for which I'd like to gather some feedback beforehand is how
to trigger method validation. I think we all agree that BV itself
should only provide the API and meta-model for method validation, but
it shouldn't actually trigger a validation of method level
constraints.

Instead this should be task of technologies integrating the method
validation feature to decide whether a validation is needed or not and
if so delegate that validation to BV.

The following options were mentioned at some time:

#1 Use @Valid

This would be semantically wrong IMO. @Valid is only a marker for
cascaded validation, but it shouldn't cause a validation itself.

#2 Define an annotation such as @javax.validation.ValidateGroups within BV

	@ValidateGroups({Group1.class, Group2.class})
	public class OrderService {

		@NotNull
		public Order placeOrder(@NotNull(groups=Group1.class) @Size(min=3,
max=20) String customerCode, @NotNull Item item, @Min(1) int quantity)
{ //... }

	}

This annotation could be discovered by interceptors/proxies etc. which
then would trigger a validation of the method constraints. The method
could be defined on a class level as well as on method level (with the
latter having precedence in case of conflicts).

We could surely define such an annotation and specify it semantics,
but I'm unsure how that would actually work out with technologies
using that feature. Taking CDI for example, AFAIK the annotation would
have to be annotated with the @InterceptorBinding meta annotation. I
don't know whether/how it would be possible that we define the "basic"
annotation, while integrators "enrich" it with the meta data they
require.

#3 Don't define anything related in BV, leave that completely to integrators

CDI could define a proper interceptor binding annotation, others could
use some XML based configuration etc.

Personally I think we could go for #2 and define an annotation to be
used by integrators (e.g. by checking for the annotation, Spring might
define a related point cut etc.). We would recommend to trigger
validation based on this annotation where possible and hopeful would
cover most cases that way. Integrators would still be free to define
their own means of triggering a validation if required.

Any thoughts? Are there any other alternatives?

--Gunnar


More information about the beanvalidation-dev mailing list