Cool Stuff !! +1 2011/7/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;

BTW I forgot but do we support Constructor validation? On 8 juil. 2011, at 16:02, Emmanuel Bernard wrote:

Hi, IMO that would be a useful feature. The following approaches came up when discussing the idea earlier this year [1]: 1) A generic approach in the spirit of @ScriptAssert which would allow to use script expressions in place like this: @ParameterAssert(script="args[1].before(args[2])", lang="javascript") void bookHotel(@NotNull @Valid Customer customer, Date from, Date to); This could also be combined with a parameter naming approach (see HV-409 [2]): @ParameterAssert(script="from.before(to)", lang="javascript") void bookHotel(@NotNull @Valid Customer customer, @Named("from") Date from, @Named("to") Date to); 2) An approach using dedicated constraints/validators: @DateParameterCheck void bookHotel(@NotNull @Valid Customer customer, Date from, Date to); The validator for the constraint would get passed the parameter values as array/list, maybe one would have a new interface MethodConstraintValidator for this: public class DateParameterCheckValidator implements MethodConstraintValidator<DateParameterCheck> { public void initialize(DateParameterCheck constraint) {} public boolean isValid(Object[] parameterValues, ConstraintValidatorContext context) { return ((Date)parameterValues[1]).before((Date)parameterValues[2]); } } As this is pretty un-safe, there also was the idea of supporting typed validators like this: public class DateParameterCheckValidator implements MethodConstraintValidator<DateParameterCheck> { public void initialize(DateParameterCheck constraint) {} public boolean isValid(Customer customer, Date from, Date to, ConstraintValidatorContext context) { return from.before(to); } } Such a validator would need an isValid() method for each method annotated with the constraint. You found that "quite interesting" :) Hardy also expressed some constraints that such a parameter constraint couldn't be easily distinguished from a return value constraint. IMO for the sake of completeness we should. This wouldn't add much conceptual complexity or implementation efforts. Though probably not all integration layers (such as Seam Validation/CDI) would use it depending on their interception mechanism. I guess it's best to continue the discussion at BVAL-232. --Gunnar [1] http://lists.jboss.org/pipermail/hibernate-dev/2011-February/005997.html [2] http://opensource.atlassian.com/projects/hibernate/browse/HV-409 2011/7/8 George Gastaldi <gegastaldi(a)gmail.com&gt;: > I think you should. > > 2011/7/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > >>> >> On 8 juil. 2011, at 16:02, Emmanuel Bernard wrote: >> >> > Do you think we should support the following? >> > >> > @DateInOrder >> > void bookHotel(@NotNull @Valid Customer customer, Date from, Date to); >> > >> > ie like we have properly level and class level constraints, we could get >> method level constraints receiving all the parameters and raising >> constraints violations if necessary. >> > >> > Emmanuel >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

+1 Good idea!! --Kevin Le 8 juil. 2011 à 16:03, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; a écrit :