Re: [bv-dev] Method level validation

I think this would make things quite complex. Users would have to provide two annotations and a validator. How would the validators look for the given example? I'm also unsure about how well that actually reads. How does one know that @Duplicated.Duplicate relates to @Duplicated? --Gunnar 2011/9/16 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > That's a nice idea > class User { > @Duplicated > String password; > @Duplicated.Duplicate > String duplicatedPassword; > } > class { > @Causality > Date checkIn; > @Causality.After > Date checkout; > } > This exact model does not scale if several string or dates need to be > compared and is weak on inheritance. A full scale qualifier model might be > nice but it's one or two additional annotations to define per type. > Thoughts? > > On 8 sept. 2011, at 22:15, Gerhard Petracek wrote: > > as an alternative we could think about a solution >similar< to cdi > qualifiers. that would be also useful for cross-field validation. > i would like to suggest a wiki which shows all possibilities side by side (+ > examples). > regards, > gerhard > > > > 2011/9/8 Hardy Ferentschik <hardy(a)hibernate.org&gt; >> >> On Wed, 07 Sep 2011 22:55:47 +0200, Sebastian Thomschke >> <sebastian.thomschke(a)web.de&gt; wrote: >> >>> Its a very unfortunate limitation in Java's reflection API that it does >>> not provide the ability to determine the declared parameter names. OVal >>> provides a pluggable parameter name resolver, with a very simple >>> interface: >>> >>> public interface ParameterNameResolver >>> { >>> String[] getParameterNames(Constructor< ? > constructor) throws >>> ReflectionException; >>> String[] getParameterNames(Method method) throws >>> ReflectionException; >>> } >> >> I like the idea of introducing an interface for parameter name resolution. >> The default and simple implementation would be the enumerated names. >> Other implementations could be based on byte code enhancing (like >> mentioned here) >> or a meta model created by an annotation processor (like Kevin suggested >> in HV-409). >> >> --Hardy >> >> >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev