|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You're right, I meant to say "favoured is option 1". The proposal is also written in that spirit.
Regarding the Liskov substitution principle, do we really have a problem with that in option 1? The proposal says, @ConvertGroup is only allowed where @Valid is allowed. For method parameters that means only at the top-most version of an overridden method due to the rules outlined in section 4.5.5. So you effectively you can't specify @ConvertGroup on parameters of a method several times in a hierarchy. For return values, we'd merge the @ConvertGroup annotations from the hierarchy, as we do with constraints. The return value constraints are to be obeyed by the method implementor who knows all @ConvertGroup annotations from the hierarchy.
So I think there shouldn't really be a problem with 1).