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>:
That's a nice idea
class User {
@Duplicated
String password;
(a)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>
>
> On Wed, 07 Sep 2011 22:55:47 +0200, Sebastian Thomschke
> <sebastian.thomschke(a)web.de> 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