[hibernate-issues] [Hibernate-JIRA] Commented: (HV-421) Reconsider behavior of parameter validation for inheritance hierarchies

[Gunnar Morling (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=39965#action_39965 ] 

Gunnar Morling commented on HV-421:
-----------------------------------

Yes, this applies only to parameter validation. I implemented the checks as described above in https://github.com/gunnarmorling/hibernate-validator/commit/be407914826c4e91efe1f651596490025d3e0e9e (just have to do some clean-ups before I create a pull request). For return value validation all constraints in the hierarchy are joined, as it is no problem to ensure harder post-conditions than a client would expect.

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?

> 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira