Re: [bv-dev] Should getters be considered methods during validation
i had a nice discussion with matt.
since bv 1.0 only supports one validation.xml, i'm ok with a package config
in validation.xml.
however, package annotations are in most cases just unexpected (and
error-prone).
(e.g. in deltaspike we dropped such annotations because of that.)
@IsInvariant vs @ValidateOnCall:
still +1 for @ValidateOnCall - imo it's easier for users, because it
describes what will be triggered.
regards,
gerhard
2012/12/12 Hardy Ferentschik <hardy(a)hibernate.org>
+1 for 2b as well and I am fine with package annotation. Given that
many
people group their packages
around things like domain vs service classes, I think it can make
configuration easier.
I have to admit that 1b is growing on me, if getters would just not be
excluded per default.
In contrast to Sebastian I actually think that if a user configures its
app to use method validation via some sort of interceptor or similar he
wants it to occur for all methods. If a getter is annotated with @NotNull
and I call this method I don't care whether
is is returning a state variable or whether this is a calculated value.
The returned value is supposed to be non
null.
Note, I am still against enabling method validation per default in a CDI
environment. I still think it should an active choice to enable the
appropriate technology. This also mitigates the problem of backwards
compatibility imo.
--Hardy
On 11 Jan 2012, at 7:32 PM, Gerhard Petracek <gerhard.petracek(a)gmail.com>
wrote:
> +1 for 2.b but -1 for a package annotation and/or config.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
Attachments:
- attachment.html (text/html — 2.5 KB)