Re: [bv-dev] Constructor validation
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