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>
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