[bv-dev] Constructor validation

[Hardy Ferentschik]

Answers inline

On Dec 4, 2011, at 4:50 PM, Gunnar Morling wrote:

>> - which visibilities do we support? public, private, package, protected?
>> all?
> 
> Is there any reason to limit this? If not, I wouldn't restrict the
> supported visibility from the Bean Validation side. I think this
> mainly depends on how method validation is integrated.

+1. I don't think that there is a reason to restrict that

>> - inheritance: you pass a java.lang.Method object of class A to
>> validateMethodParameters() and an object of class B extending class A
>> which overrides this method. Which constraints are checked, the ones of
>> the method declared on class A, the ones declared on the method of class
>> B or the sum of the methods in A & B?
> 
> That's a very good question.

Gunnar already summarized this quite well. For your reference there is a 
discussion about this also on the Hibernate Validator issue tracker
https://hibernate.onjira.com/browse/HV-421

I consider this the most important decisions we have to make/specify related
to method level validation.

Other important questions are:

* Do we provide the possibility to specify parameter names (HV-409)
  We already discussed this on this list and I think we agreed that an interface approach makes
  sense here
* How do we extend the metadata API?


>> - When you add a method return value constraint to a parameterized
>> method and you do Validator.validate(object), thoses constraints are not
>> evaluated. But when you add a constraint to a getter-style method (which
>> also looks and actually is a method return value constraint). They are
>> evaluated by Validator.validate(object). What if someone wants to add a
>> method return value constraint to a getter-style method, that is not
>> evaluated when Validator.validate(object) is executed but after the
>> method itself has been invoked? In OVal you have to explicitely add the
>> @IsInvariant annotation to getter methods if their constraints should be
>> evaluated too when Validator.validate(object) is executed. If so, OVal
>> will invoke the getter and test the returned value against the
>> constraints specified.

I think the ability to clearly separate property validation from return value validation makes 
sense.

--Hardy