hi @ all,

@ "treat getter-methods as regular methods for method-validation":
there are cases which would benefit from it, but such a behaviour can also break a lot!

-> if we support it:
imo we need a global config option as well as an api for de-/activating it. in case of the api we would also need a possibility for de-/activating it dynamically for one validation process. e.g. in a jsf application there is only one phase (invoke application) of the request-lifecycle for which such a feature could make sense (and for a lot of applications not even there). in all other phases it just doesn't make sense and it would just be a performance penalty which only leads to side-effects you can hardly control (if a jsf implementation doesn't handle it explicitly).

that's imo also true for many other constellations which are independent of jsf.

regards,
gerhard



2012/11/9 Hardy Ferentschik <hardy@hibernate.org>
I have to back up Gunnar on this one on all counts :-)

On 9 Jan 2012, at 10:13 AM, Gunnar Morling wrote:

> Generally I don't think that considering getters during method validation really is a problem. So I wouldn't really have a problem with this being the default behavior (which it also is in the proprietary API in HV 4.3). I'd prefer that over excluding certain named methods from method validation as this goes against the principle of least surprise and would feel like an inconsistency to me.

+1

> But if validating getters during method validation really is a problem, I'd expect this to be the case generally throughout an application or system. Taking the example of JPA entities which used to be validated upon persisting only and now would their property constraints get validated upon getter invocation, then I'd prefer to disable getter validation globally instead of marking each individual property with an annotation.

+1

> If I as a user really needed a configuration per element, I could do so using validation groups. If for instance single constraints should not be validated upon getter invocation, I could use a group like this:

+1

Are not more people have an opinion on this issue?

--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev