[
http://opensource.atlassian.com/projects/hibernate/browse/HV-421?page=com...
]
Hardy Ferentschik commented on HV-421:
--------------------------------------
{quote}
Parameter constraint checking currently happens when creating the meta-model (constructor
of BeanMetaDataImpl). This means a bean with illegal method parameter constraints would
cause an exception also if no method validation but only standard bean validation is
performed on that bean. Personally I think such a fail fast approach is always preferrable
(and if anyone annotes method parameters with constraint annotations he very likely will
perform method validation at one point). WDYT?
{quote}
Generally I would also prefer with the fail fast approach. It is also consistent with the
parsing/creating of BV constraints and we are talking about
{{ConstraintDefinitionException}} here.
Now comes the but. The method level validation is not part of the spec and potentially
there could be other attempts to implement some form of method level validation. Or maybe
some people used the constraints annotations on method parameters for
"documentation" purposes. Maybe we have to be more conservative here to ensure
we don't break pure Bean Validation behavior.
Reconsider behavior of parameter validation for inheritance
hierarchies
-----------------------------------------------------------------------
Key: HV-421
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-421
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Reporter: Gunnar Morling
Assignee: Gunnar Morling
Fix For: 4.2.0.Beta2
Let A extend B and A#foo() override B#foo(). When validating an invocation of A#foo() the
current implementation will evaluate all parameter constraints defined at A#foo() *and*
B#foo(). That way foo()'s preconditions defined in B are strengthened by A.
According to the ["Programming by
contract"|http://en.wikipedia.org/wiki/Programming_by_contract] article on WP this is
not allowed, subtypes may only weaken preconditions defined by supertypes. The common
implementation pattern for this is to combine the preconditions within a hierarchy by a
logical OR, meaning the weakest precondition in the hierarchy applies.
Note that postconditions (return value constraints) may be strengthened (but not
weakened) by subtypes. Therefore the current implementation (AND combination) should be
correct here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira