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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev