[hibernate-dev] [Validator] Method level validation and cross parameter validator

Gunnar Morling gunnar.morling at googlemail.com
Sat Feb 19 08:39:38 EST 2011


Hi,

a scripting-based approach as described by Hardy is also the first idea
which would come to my mind.

Maybe @ScriptAssert could even be re-used for this (I also thought about
providing support for @ScriptAssert for property validation btw.). I'd like
this idea as the contract is tightly integrated with the annotated method
(e.g. it would be part of the method's JavaDoc etc.). As down-side there is
the lack of type and refactoring safety.

Another idea might be to support method-specific constraints similar to
custom class-level constraints which would provide more type safety:

public class BookingService {
 @ValidBooking
public Reservation book(Date startDate, Date endDate) {
//...
}
}

@ValidBooking would be a custom annotation type:

@Target({ METHOD })
@Retention(RUNTIME)
@MethodConstraint(validatedBy = {ValidBookingValidator.class})
public @interface ValidBooking{}

ValidBookingValidator would be a custom method constraint validator
implementation with a specific isValid() method:

public class ValidBookingValidator implements MethodValidator<ValidBooking>
{
 public void initialize(ValidBooking constraintAnnotation) {
}

public boolean isValid(Date startDate, Date endDate,
ConstraintValidatorContext constraintContext) {
return startDate.before(endDate);
}
}

Ideally this type would be generated by an annotation processor or similar.
There might be an isValid() method for each different method
signature annotated with @ValidBooking found by the generator.

Gunnar

2011/2/18 Hardy Ferentschik <hibernate at ferentschik.de>

> On Fri, 18 Feb 2011 09:01:16 +0100, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>
> > Reading the Google design by contract work, I realized that we do not
> > cover cross-parameter validation in method-level validation.
>
> I assume you are talking about cofoja (http://code.google.com/p/cofoja),
> right?
>
> > //We want to make sure departure is after arrival.
> > void book(Date arrival, Date departure);
> >
> > Any idea on ow best to address that?
>
> Some ideas:
>
> Introduce an equivalent to class level validators:
>
>  @DateParameterCheck
>   void book(Date arrival, Date departure);
>
> @MyMethodValidator could contain a marker annotation so that we know that
> we
> have a method level validation. At first thought we would have to pass
> object arrays
> to the validator implementations. This is of course at odds with the type
> safety approach
> of BV.
> Also if the method has a return value it is not directly clear by reading
> the code
> whether the return value would be validated or the parameters.
>
> An alternative would be something similar to @ScriptAssert:
>
>  @ParameterCheck("arg[0].before(arg[1])")
>   void book(Date arrival, Date departure);
>
> Gunnar already thought about naming parameters using @Named (HV-409),
> maybe we could also do
> something like:
>
>  @ParameterCheck("arrival.before(departure)")
>  void book(@Named("arrival") Date arrival, @Named("departure") Date
> departure);
>
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



More information about the hibernate-dev mailing list