[bv-dev] Method Validation: Why Example 4.11 should be allowed

[Paul Benedict]

Thanks Emmanuel. I am sure the poll will bring interesting results.

In the mean time, I am looking for some background information here. I
would like to understand this reasoning a bit better. As I said, I was
reading the Hibernate Validator guide and read (not news to me) that
annotations on beans can be compounded: "Constraint annotations are
aggregated if methods are overridden."

Yet one of the arguments made to me (against allowing constraint
redefinition on methods) is that the caller doesn't know if
redefinition occurred. However, I see that's exactly the case today
regarding constraint inheritance on beans -- subclasses can add more
constraints by overriding superclass methods. So a client might be
using a subclass, unbeknownst to the client, that has more constraints
than what superclass/interface he compiled against.

My question is really why treat validation different between beans and
method parameters? Why allow the former but disallow the latter? The
way we treat beans today is what I would expect even for method
validation (hence my emails). I honestly see no difference so I find
the difference in validating behavior puzzling. My question isn't
rhetorical so any answer is appreciated to help better understand the
opposing perspective. Thank you.

Paul

On Mon, Aug 27, 2012 at 9:12 AM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> Just to get a better understanding of the dynamic here.
> Can you all vote on what you think is the best approach for Bean Validation 1.1
> http://www.doodle.com/qp78u6mqzetuas7p
>