12:16 p.m.
While we still decide what to do in which order, I'd like to start thinking about
method level validation in parallel.
Probably the biggest feature for this new round ( http://beanvalidation.org/roadmap/ ) is
method level validation.
## Goal
Offer the ability to:
- annotate method and constructor parameters and return values with Bean Validation
constraints.
- provide validation methods to validate a method / constructor given a set of parameters
This set of methods will be used by framework controlling the method execution cycle (CDI,
JAX-RS, aspect oriented frameworks etc).
https://hibernate.onjira.com/browse/BVAL-232
We need to explore this feature to clarify what we want to support, how we want to support
it, how it integrates with Bean Validation 1.0.
## Usefulness
This method will be useful to various other specifications including CDI and JAX-RS.
That's why I'd like to stabilize this feature as early as possible.
## Proposals
Hibernate Validator has an implementation of such feature and I am sure OVal, Apache Bean
Validation and others have something similar. Let's start with describing what we have
and start the discussion from here.
Gunnar, could to take the lead on the Hibernate Validator version? You know this area
best.
Emmanuel
11:13 p.m.
Hi,
Gunnar, could to take the lead on the Hibernate Validator version?
You know this area best.
Sure. What we have in HV [1], [2] is pretty much based on appendix C
of BV 1.0 [3]. More specifically that is:
* IF MethodValidator:
public interface MethodValidator {
<T> Set<MethodConstraintViolation<T>> validateParameter(T object,
Method method, Object parameterValue, int parameterIndex, Class<?>...
groups);
<T> Set<MethodConstraintViolation<T>> validateAllParameters(T object,
Method method, Object[] parameterValues, Class<?>... groups);
<T> Set<MethodConstraintViolation<T>> validateReturnValue(T object,
Method method, Object returnValue, Class<?>... groups);
TypeDescriptor getConstraintsForType(Class<?> clazz);
}
In BV these methods should go into javax.validation.Validator (plus
validateConstructorParameters or similar).
* IF MethodConstraintViolation which extends ConstraintViolation by
adding getMethod(), getParameterIndex() etc. to specify the source of
a violation.
* MethodConstraintViolationException, wrapping a set of
MethodConstraintViolations and to be thrown by integrators of the
method validation feature.
* Extension to the constraint meta data API based on IF TypeDescriptor:
public interface TypeDescriptor extends ElementDescriptor {
boolean isTypeConstrained();
Set<MethodDescriptor> getConstrainedMethods();
MethodDescriptor getConstraintsForMethod(String methodName,
Class<?>... parameterTypes);
BeanDescriptor getBeanDescriptor();
}
In BV 1.1 this should be merged with BeanDescriptor (which in turn
should be renamed to TypeDescriptor IMO as it isn't restricted to
JavaBeans any more).
* Extension to the programmatic API [4] allowing to specify method
constraints programmatically like this:
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
.method( "drive", String.class, Integer.class )
.parameter( 0 )
.constraint( new NotNullDef() )
.constraint( new MinDef().value ( 1 ) )
.returnValue()
.valid();
HibernateValidatorConfiguration config = Validation.byProvider(
HibernateValidator.class ).configure();
config.addMapping( mapping );
Validator validator = config.buildValidatorFactory().getValidator();
What we don't have:
* constructor validation
* cross-parameter validation as discussed in BV-232.
* parameter constraints may only be specified at the "lowest version"
of an overridden method, see [5]. Though I don't think that this
restriction is really an issue.
* ability to specify parameter names, see [6].
@Hardy: Do see anything missing?
--Gunnar
[1] HV reference guide on method validation:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/val...
[2] HV's method validation API:
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hiber...
[3] BV 1.0, Appendix C:
http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
[4] HV's programmatic constraint API:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
[5] Using method constraints in type hierarchies:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
[6] Specifying parameter names: https://hibernate.onjira.com/browse/HV-409
2011/9/6 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> While we still decide what to do in which order, I'd like to start thinking about
method level validation in parallel.
>
> Probably the biggest feature for this new round ( http://beanvalidation.org/roadmap/
) is method level validation.
>
> ## Goal
>
> Offer the ability to:
>
> - annotate method and constructor parameters and return values with Bean Validation
constraints.
> - provide validation methods to validate a method / constructor given a set of
parameters
>
> This set of methods will be used by framework controlling the method execution cycle
(CDI, JAX-RS, aspect oriented frameworks etc).
>
> https://hibernate.onjira.com/browse/BVAL-232
>
> We need to explore this feature to clarify what we want to support, how we want to
support it, how it integrates with Bean Validation 1.0.
>
> ## Usefulness
>
> This method will be useful to various other specifications including CDI and JAX-RS.
That's why I'd like to stabilize this feature as early as possible.
>
> ## Proposals
>
> Hibernate Validator has an implementation of such feature and I am sure OVal, Apache
Bean Validation and others have something similar. Let's start with describing what we
have and start the discussion from here.
>
Gunnar, could to take the lead on the Hibernate Validator version?
You know this area best.
>
> Emmanuel
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
8:49 p.m.
hi,
@MethodValidator
+1 for the concept in general
however, if there isn't a reason for using T object compared to Class<T>
clazz (see [1]) as parameter, i would prefer Class<T>.
@BeanDescriptor (renaming it to TypeDescriptor)
it's a type-safe change - but still -1
@named parameters:
(for the spec.) i don't like the idea to re-use @Named for it (the package
javax.inject and therefore the dependency in general look strange from the
perspective of bv)
imo we should re-visit cross-field validation. a solution for it might
influence this topic as well (to keep it consistent).
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/bval-...
2011/9/6 Gunnar Morling <gunnar.morling(a)googlemail.com>
Hi,
> Gunnar, could to take the lead on the Hibernate Validator version? You
know this area best.
Sure. What we have in HV [1], [2] is pretty much based on appendix C
of BV 1.0 [3]. More specifically that is:
* IF MethodValidator:
public interface MethodValidator {
<T> Set<MethodConstraintViolation<T>> validateParameter(T
object,
Method method, Object parameterValue, int parameterIndex, Class<?>...
groups);
<T> Set<MethodConstraintViolation<T>> validateAllParameters(T
object,
Method method, Object[] parameterValues, Class<?>... groups);
<T> Set<MethodConstraintViolation<T>> validateReturnValue(T
object,
Method method, Object returnValue, Class<?>... groups);
TypeDescriptor getConstraintsForType(Class<?> clazz);
}
In BV these methods should go into javax.validation.Validator (plus
validateConstructorParameters or similar).
* IF MethodConstraintViolation which extends ConstraintViolation by
adding getMethod(), getParameterIndex() etc. to specify the source of
a violation.
* MethodConstraintViolationException, wrapping a set of
MethodConstraintViolations and to be thrown by integrators of the
method validation feature.
* Extension to the constraint meta data API based on IF TypeDescriptor:
public interface TypeDescriptor extends ElementDescriptor {
boolean isTypeConstrained();
Set<MethodDescriptor> getConstrainedMethods();
MethodDescriptor getConstraintsForMethod(String methodName,
Class<?>... parameterTypes);
BeanDescriptor getBeanDescriptor();
}
In BV 1.1 this should be merged with BeanDescriptor (which in turn
should be renamed to TypeDescriptor IMO as it isn't restricted to
JavaBeans any more).
* Extension to the programmatic API [4] allowing to specify method
constraints programmatically like this:
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
.method( "drive", String.class, Integer.class )
.parameter( 0 )
.constraint( new NotNullDef() )
.constraint( new MinDef().value ( 1 ) )
.returnValue()
.valid();
HibernateValidatorConfiguration config = Validation.byProvider(
HibernateValidator.class ).configure();
config.addMapping( mapping );
Validator validator = config.buildValidatorFactory().getValidator();
What we don't have:
* constructor validation
* cross-parameter validation as discussed in BV-232.
* parameter constraints may only be specified at the "lowest version"
of an overridden method, see [5]. Though I don't think that this
restriction is really an issue.
* ability to specify parameter names, see [6].
@Hardy: Do see anything missing?
--Gunnar
[1] HV reference guide on method validation:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/val...
[2] HV's method validation API:
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hiber...
[3] BV 1.0, Appendix C:
http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
[4] HV's programmatic constraint API:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
[5] Using method constraints in type hierarchies:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
[6] Specifying parameter names: https://hibernate.onjira.com/browse/HV-409
2011/9/6 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> While we still decide what to do in which order, I'd like to start
thinking about method level validation in parallel.
>
> Probably the biggest feature for this new round (
http://beanvalidation.org/roadmap/ ) is method level validation.
>
> ## Goal
>
> Offer the ability to:
>
> - annotate method and constructor parameters and return values with Bean
Validation constraints.
> - provide validation methods to validate a method / constructor given a
set of parameters
>
> This set of methods will be used by framework controlling the method
execution cycle (CDI, JAX-RS, aspect oriented frameworks etc).
>
> https://hibernate.onjira.com/browse/BVAL-232
>
> We need to explore this feature to clarify what we want to support, how
we want to support it, how it integrates with Bean Validation 1.0.
>
> ## Usefulness
>
> This method will be useful to various other specifications including CDI
and JAX-RS. That's why I'd like to stabilize this feature as early as
possible.
>
> ## Proposals
>
> Hibernate Validator has an implementation of such feature and I am sure
OVal, Apache Bean Validation and others have something similar. Let's start
with describing what we have and start the discussion from here.
>
> Gunnar, could to take the lead on the Hibernate Validator version? You
know this area best.
>
> Emmanuel
> _______________________________________________
> 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
9:50 p.m.
Cross parameter validation seems like a potentially thorny issue we should
try and consider alongside this to me as well. (Approach 2a on BVAL-232
seems reasonable?)
I'm not so keen on @Named for identifying the parameters, for the same
reasons as Gerhard mentions but also just because the parameter name becomes
duplicated. However it looks as though Kevin has suggested an alternative in
a comment on Gunnar's reference [6] and that there may be an existing
implementation in at least OVal too?
Regards
Richard
On 7 September 2011 19:49, Gerhard Petracek <gerhard.petracek(a)gmail.com>wrote:
hi,
@MethodValidator
+1 for the concept in general
however, if there isn't a reason for using T object compared to Class<T>
clazz (see [1]) as parameter, i would prefer Class<T>.
@BeanDescriptor (renaming it to TypeDescriptor)
it's a type-safe change - but still -1
@named parameters:
(for the spec.) i don't like the idea to re-use @Named for it (the package
javax.inject and therefore the dependency in general look strange from the
perspective of bv)
imo we should re-visit cross-field validation. a solution for it might
influence this topic as well (to keep it consistent).
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/bval-...
2011/9/6 Gunnar Morling <gunnar.morling(a)googlemail.com>
> Hi,
>
> > Gunnar, could to take the lead on the Hibernate Validator version? You
> know this area best.
>
> Sure. What we have in HV [1], [2] is pretty much based on appendix C
> of BV 1.0 [3]. More specifically that is:
>
> * IF MethodValidator:
>
> public interface MethodValidator {
>
> <T> Set<MethodConstraintViolation<T>> validateParameter(T
object,
> Method method, Object parameterValue, int parameterIndex, Class<?>...
> groups);
>
> <T> Set<MethodConstraintViolation<T>>
validateAllParameters(T
> object,
> Method method, Object[] parameterValues, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateReturnValue(T
object,
> Method method, Object returnValue, Class<?>... groups);
>
> TypeDescriptor getConstraintsForType(Class<?> clazz);
> }
>
> In BV these methods should go into javax.validation.Validator (plus
> validateConstructorParameters or similar).
>
> * IF MethodConstraintViolation which extends ConstraintViolation by
> adding getMethod(), getParameterIndex() etc. to specify the source of
> a violation.
>
> * MethodConstraintViolationException, wrapping a set of
> MethodConstraintViolations and to be thrown by integrators of the
> method validation feature.
>
> * Extension to the constraint meta data API based on IF TypeDescriptor:
>
> public interface TypeDescriptor extends ElementDescriptor {
>
> boolean isTypeConstrained();
>
> Set<MethodDescriptor> getConstrainedMethods();
>
> MethodDescriptor getConstraintsForMethod(String methodName,
> Class<?>... parameterTypes);
>
> BeanDescriptor getBeanDescriptor();
> }
>
> In BV 1.1 this should be merged with BeanDescriptor (which in turn
> should be renamed to TypeDescriptor IMO as it isn't restricted to
> JavaBeans any more).
>
> * Extension to the programmatic API [4] allowing to specify method
> constraints programmatically like this:
>
> ConstraintMapping mapping = new ConstraintMapping();
> mapping.type( Car.class )
> .method( "drive", String.class, Integer.class )
> .parameter( 0 )
> .constraint( new NotNullDef() )
> .constraint( new MinDef().value ( 1 ) )
> .returnValue()
> .valid();
>
> HibernateValidatorConfiguration config = Validation.byProvider(
> HibernateValidator.class ).configure();
> config.addMapping( mapping );
> Validator validator = config.buildValidatorFactory().getValidator();
>
> What we don't have:
>
> * constructor validation
>
> * cross-parameter validation as discussed in BV-232.
>
> * parameter constraints may only be specified at the "lowest version"
> of an overridden method, see [5]. Though I don't think that this
> restriction is really an issue.
>
> * ability to specify parameter names, see [6].
>
> @Hardy: Do see anything missing?
>
> --Gunnar
>
>
> [1] HV reference guide on method validation:
>
>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/val...
> [2] HV's method validation API:
>
>
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hiber...
> [3] BV 1.0, Appendix C:
> http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
> [4] HV's programmatic constraint API:
>
>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
> [5] Using method constraints in type hierarchies:
>
>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
> [6] Specifying parameter names:
> https://hibernate.onjira.com/browse/HV-409
>
>
> 2011/9/6 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> > While we still decide what to do in which order, I'd like to start
> thinking about method level validation in parallel.
> >
> > Probably the biggest feature for this new round (
> http://beanvalidation.org/roadmap/ ) is method level validation.
> >
> > ## Goal
> >
> > Offer the ability to:
> >
> > - annotate method and constructor parameters and return values with Bean
> Validation constraints.
> > - provide validation methods to validate a method / constructor given a
> set of parameters
> >
> > This set of methods will be used by framework controlling the method
> execution cycle (CDI, JAX-RS, aspect oriented frameworks etc).
> >
> > https://hibernate.onjira.com/browse/BVAL-232
> >
> > We need to explore this feature to clarify what we want to support, how
> we want to support it, how it integrates with Bean Validation 1.0.
> >
> > ## Usefulness
> >
> > This method will be useful to various other specifications including CDI
> and JAX-RS. That's why I'd like to stabilize this feature as early as
> possible.
> >
> > ## Proposals
> >
> > Hibernate Validator has an implementation of such feature and I am sure
> OVal, Apache Bean Validation and others have something similar. Let's start
> with describing what we have and start the discussion from here.
> >
> > Gunnar, could to take the lead on the Hibernate Validator version? You
> know this area best.
> >
> > Emmanuel
> > _______________________________________________
> > 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
10:31 p.m.
However it looks as though Kevin has suggested an alternative in
a comment on Gunnar's reference [6] and that there may be an existing
implementation in at least OVal too?
Sebastian I'm vaguely remembering you're having some sort of pluggable
approach in OVal for parameter name providers. Maybe you could provide
some more details?
--Gunnar
Regards
Richard
On 7 September 2011 19:49, Gerhard Petracek <gerhard.petracek(a)gmail.com>
wrote:
>
> hi,
> @MethodValidator
> +1 for the concept in general
> however, if there isn't a reason for using T object compared to Class<T>
> clazz (see [1]) as parameter, i would prefer Class<T>.
> @BeanDescriptor (renaming it to TypeDescriptor)
> it's a type-safe change - but still -1
> @named parameters:
> (for the spec.) i don't like the idea to re-use @Named for it (the package
> javax.inject and therefore the dependency in general look strange from the
> perspective of bv)
> imo we should re-visit cross-field validation. a solution for it might
> influence this topic as well (to keep it consistent).
> regards,
> gerhard
> [1]
>
https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/bval-...
> 2011/9/6 Gunnar Morling <gunnar.morling(a)googlemail.com>
>>
>> Hi,
>>
>> > Gunnar, could to take the lead on the Hibernate Validator version? You
>> > know this area best.
>>
>> Sure. What we have in HV [1], [2] is pretty much based on appendix C
>> of BV 1.0 [3]. More specifically that is:
>>
>> * IF MethodValidator:
>>
>> public interface MethodValidator {
>>
>> <T> Set<MethodConstraintViolation<T>>
validateParameter(T object,
>> Method method, Object parameterValue, int parameterIndex, Class<?>...
>> groups);
>>
>> <T> Set<MethodConstraintViolation<T>>
validateAllParameters(T
>> object,
>> Method method, Object[] parameterValues, Class<?>... groups);
>>
>> <T> Set<MethodConstraintViolation<T>>
validateReturnValue(T
>> object,
>> Method method, Object returnValue, Class<?>... groups);
>>
>> TypeDescriptor getConstraintsForType(Class<?> clazz);
>> }
>>
>> In BV these methods should go into javax.validation.Validator (plus
>> validateConstructorParameters or similar).
>>
>> * IF MethodConstraintViolation which extends ConstraintViolation by
>> adding getMethod(), getParameterIndex() etc. to specify the source of
>> a violation.
>>
>> * MethodConstraintViolationException, wrapping a set of
>> MethodConstraintViolations and to be thrown by integrators of the
>> method validation feature.
>>
>> * Extension to the constraint meta data API based on IF TypeDescriptor:
>>
>> public interface TypeDescriptor extends ElementDescriptor {
>>
>> boolean isTypeConstrained();
>>
>> Set<MethodDescriptor> getConstrainedMethods();
>>
>> MethodDescriptor getConstraintsForMethod(String methodName,
>> Class<?>... parameterTypes);
>>
>> BeanDescriptor getBeanDescriptor();
>> }
>>
>> In BV 1.1 this should be merged with BeanDescriptor (which in turn
>> should be renamed to TypeDescriptor IMO as it isn't restricted to
>> JavaBeans any more).
>>
>> * Extension to the programmatic API [4] allowing to specify method
>> constraints programmatically like this:
>>
>> ConstraintMapping mapping = new ConstraintMapping();
>> mapping.type( Car.class )
>> .method( "drive", String.class, Integer.class )
>> .parameter( 0 )
>> .constraint( new NotNullDef() )
>> .constraint( new MinDef().value ( 1 ) )
>> .returnValue()
>> .valid();
>>
>> HibernateValidatorConfiguration config = Validation.byProvider(
>> HibernateValidator.class ).configure();
>> config.addMapping( mapping );
>> Validator validator = config.buildValidatorFactory().getValidator();
>>
>> What we don't have:
>>
>> * constructor validation
>>
>> * cross-parameter validation as discussed in BV-232.
>>
>> * parameter constraints may only be specified at the "lowest version"
>> of an overridden method, see [5]. Though I don't think that this
>> restriction is really an issue.
>>
>> * ability to specify parameter names, see [6].
>>
>> @Hardy: Do see anything missing?
>>
>> --Gunnar
>>
>>
>> [1] HV reference guide on method validation:
>>
>>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/val...
>> [2] HV's method validation API:
>>
>>
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hiber...
>> [3] BV 1.0, Appendix C:
>> http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
>> [4] HV's programmatic constraint API:
>>
>>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
>> [5] Using method constraints in type hierarchies:
>>
>>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
>> [6] Specifying parameter names:
>> https://hibernate.onjira.com/browse/HV-409
>>
>>
>> 2011/9/6 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> > While we still decide what to do in which order, I'd like to start
>> > thinking about method level validation in parallel.
>> >
>> > Probably the biggest feature for this new round (
>> > http://beanvalidation.org/roadmap/ ) is method level validation.
>> >
>> > ## Goal
>> >
>> > Offer the ability to:
>> >
>> > - annotate method and constructor parameters and return values with
>> > Bean Validation constraints.
>> > - provide validation methods to validate a method / constructor given a
>> > set of parameters
>> >
>> > This set of methods will be used by framework controlling the method
>> > execution cycle (CDI, JAX-RS, aspect oriented frameworks etc).
>> >
>> > https://hibernate.onjira.com/browse/BVAL-232
>> >
>> > We need to explore this feature to clarify what we want to support, how
>> > we want to support it, how it integrates with Bean Validation 1.0.
>> >
>> > ## Usefulness
>> >
>> > This method will be useful to various other specifications including
>> > CDI and JAX-RS. That's why I'd like to stabilize this feature as
early as
>> > possible.
>> >
>> > ## Proposals
>> >
>> > Hibernate Validator has an implementation of such feature and I am sure
>> > OVal, Apache Bean Validation and others have something similar. Let's
start
>> > with describing what we have and start the discussion from here.
>> >
>> > Gunnar, could to take the lead on the Hibernate Validator version? You
>> > know this area best.
>> >
>> > Emmanuel
>> > _______________________________________________
>> > 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
10:55 p.m.
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;
}
OVal comes with three implementations:
http://oval.svn.sourceforge.net/viewvc/oval/trunk/src/main/java/net/sf/ov...
simply returns enumerated names, e.g. param1, param2, param3
http://oval.svn.sourceforge.net/viewvc/oval/trunk/src/main/java/net/sf/ov...
requires AspectJ and that the validated classes are enhanced by an
GuardAspect. the implementation determines the real parameter names by
inspecting some static fields injected into the byte code during the
weaving process.
http://oval.svn.sourceforge.net/viewvc/oval/trunk/src/main/java/net/sf/ov...
requires the Paranamer library and uses it's
BytecodeReadingParanamerimplementation to extract the real parameter
names from the byte code.
AFAIR the general problem with reading from bytecode is that parameter
names are stored by the Java compiler for classes but not for interfaces.
OVal currently uses parameter names only for error reporting and not to
provide cross-parameter validations. To express preconditions the user
is currently limited to work with an array containing the argument
values only:
@Pre("_args[0] != _args[1]", lang="groovy")
void myMethod(String uniqueValue, String anotherUniqueValue) {
// whatever....
}
Regards,
Seb
On 07.09.2011 22:31, Gunnar Morling wrote:
> However it looks as though Kevin has suggested an alternative in
> a comment on Gunnar's reference [6] and that there may be an existing
> implementation in at least OVal too?
Sebastian I'm vaguely remembering you're having some sort of pluggable
approach in OVal for parameter name providers. Maybe you could provide
some more details?
--Gunnar
> Regards
> Richard
>
> On 7 September 2011 19:49, Gerhard Petracek<gerhard.petracek(a)gmail.com>
> wrote:
>> hi,
>> @MethodValidator
>> +1 for the concept in general
>> however, if there isn't a reason for using T object compared to
Class<T>
>> clazz (see [1]) as parameter, i would prefer Class<T>.
>> @BeanDescriptor (renaming it to TypeDescriptor)
>> it's a type-safe change - but still -1
>> @named parameters:
>> (for the spec.) i don't like the idea to re-use @Named for it (the package
>> javax.inject and therefore the dependency in general look strange from the
>> perspective of bv)
>> imo we should re-visit cross-field validation. a solution for it might
>> influence this topic as well (to keep it consistent).
>> regards,
>> gerhard
>> [1]
>>
https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/bval-...
>> 2011/9/6 Gunnar Morling<gunnar.morling(a)googlemail.com>
>>> Hi,
>>>
>>>> Gunnar, could to take the lead on the Hibernate Validator version? You
>>>> know this area best.
>>> Sure. What we have in HV [1], [2] is pretty much based on appendix C
>>> of BV 1.0 [3]. More specifically that is:
>>>
>>> * IF MethodValidator:
>>>
>>> public interface MethodValidator {
>>>
>>> <T> Set<MethodConstraintViolation<T>>
validateParameter(T object,
>>> Method method, Object parameterValue, int parameterIndex, Class<?>...
>>> groups);
>>>
>>> <T> Set<MethodConstraintViolation<T>>
validateAllParameters(T
>>> object,
>>> Method method, Object[] parameterValues, Class<?>... groups);
>>>
>>> <T> Set<MethodConstraintViolation<T>>
validateReturnValue(T
>>> object,
>>> Method method, Object returnValue, Class<?>... groups);
>>>
>>> TypeDescriptor getConstraintsForType(Class<?> clazz);
>>> }
>>>
>>> In BV these methods should go into javax.validation.Validator (plus
>>> validateConstructorParameters or similar).
>>>
>>> * IF MethodConstraintViolation which extends ConstraintViolation by
>>> adding getMethod(), getParameterIndex() etc. to specify the source of
>>> a violation.
>>>
>>> * MethodConstraintViolationException, wrapping a set of
>>> MethodConstraintViolations and to be thrown by integrators of the
>>> method validation feature.
>>>
>>> * Extension to the constraint meta data API based on IF TypeDescriptor:
>>>
>>> public interface TypeDescriptor extends ElementDescriptor {
>>>
>>> boolean isTypeConstrained();
>>>
>>> Set<MethodDescriptor> getConstrainedMethods();
>>>
>>> MethodDescriptor getConstraintsForMethod(String methodName,
>>> Class<?>... parameterTypes);
>>>
>>> BeanDescriptor getBeanDescriptor();
>>> }
>>>
>>> In BV 1.1 this should be merged with BeanDescriptor (which in turn
>>> should be renamed to TypeDescriptor IMO as it isn't restricted to
>>> JavaBeans any more).
>>>
>>> * Extension to the programmatic API [4] allowing to specify method
>>> constraints programmatically like this:
>>>
>>> ConstraintMapping mapping = new ConstraintMapping();
>>> mapping.type( Car.class )
>>> .method( "drive", String.class, Integer.class )
>>> .parameter( 0 )
>>> .constraint( new NotNullDef() )
>>> .constraint( new MinDef().value ( 1 ) )
>>> .returnValue()
>>> .valid();
>>>
>>> HibernateValidatorConfiguration config = Validation.byProvider(
>>> HibernateValidator.class ).configure();
>>> config.addMapping( mapping );
>>> Validator validator = config.buildValidatorFactory().getValidator();
>>>
>>> What we don't have:
>>>
>>> * constructor validation
>>>
>>> * cross-parameter validation as discussed in BV-232.
>>>
>>> * parameter constraints may only be specified at the "lowest
version"
>>> of an overridden method, see [5]. Though I don't think that this
>>> restriction is really an issue.
>>>
>>> * ability to specify parameter names, see [6].
>>>
>>> @Hardy: Do see anything missing?
>>>
>>> --Gunnar
>>>
>>>
>>> [1] HV reference guide on method validation:
>>>
>>>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/val...
>>> [2] HV's method validation API:
>>>
>>>
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hiber...
>>> [3] BV 1.0, Appendix C:
>>> http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
>>> [4] HV's programmatic constraint API:
>>>
>>>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
>>> [5] Using method constraints in type hierarchies:
>>>
>>>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
>>> [6] Specifying parameter names:
>>> https://hibernate.onjira.com/browse/HV-409
>>>
>>>
>>> 2011/9/6 Emmanuel Bernard<emmanuel(a)hibernate.org>:
>>>> While we still decide what to do in which order, I'd like to start
>>>> thinking about method level validation in parallel.
>>>>
>>>> Probably the biggest feature for this new round (
>>>> http://beanvalidation.org/roadmap/ ) is method level validation.
>>>>
>>>> ## Goal
>>>>
>>>> Offer the ability to:
>>>>
>>>> - annotate method and constructor parameters and return values with
>>>> Bean Validation constraints.
>>>> - provide validation methods to validate a method / constructor given a
>>>> set of parameters
>>>>
>>>> This set of methods will be used by framework controlling the method
>>>> execution cycle (CDI, JAX-RS, aspect oriented frameworks etc).
>>>>
>>>> https://hibernate.onjira.com/browse/BVAL-232
>>>>
>>>> We need to explore this feature to clarify what we want to support, how
>>>> we want to support it, how it integrates with Bean Validation 1.0.
>>>>
>>>> ## Usefulness
>>>>
>>>> This method will be useful to various other specifications including
>>>> CDI and JAX-RS. That's why I'd like to stabilize this feature as
early as
>>>> possible.
>>>>
>>>> ## Proposals
>>>>
>>>> Hibernate Validator has an implementation of such feature and I am sure
>>>> OVal, Apache Bean Validation and others have something similar. Let's
start
>>>> with describing what we have and start the discussion from here.
>>>>
>>>> Gunnar, could to take the lead on the Hibernate Validator version? You
>>>> know this area best.
>>>>
>>>> Emmanuel
>>>> _______________________________________________
>>>> 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
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:23 a.m.
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
10:15 p.m.
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
10:55 p.m.
I like the idea of introducing an interface for parameter name
resolution.
The default and simple implementation would be the enumerated names.
+1 for having such an interface. As Hardy said the default
implementation would return names like "arg0", "arg1". And each BV
provider might ship with additional implementations. The
implementation to use might be set via Validator(Factory) like the
other configurable options.
as an alternative we could think about a solution >similar< to
cdi
qualifiers. that would be also useful for cross-field validation.
Could you give some more details on what you have in mind?
i would like to suggest a wiki which shows all possibilities side by
side (+
examples).
+1 for having a wiki page. This might be useful for some collaborative
editing. Although for sharing code snippets using simple gists [1]
might be simpler. There is also a wiki functionality on github [2].
Emmanuel/Hardy: Could you enable that for the beanvalidation repository?
--Gunnar
[1] https://github.com/features/projects/wikis
[2] https://gist.github.com/
2011/9/8 Gerhard Petracek <gerhard.petracek(a)gmail.com>:
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
>
>
3:15 p.m.
On 8 sept. 2011, at 22:55, Gunnar Morling wrote:
>
> i would like to suggest a wiki which shows all possibilities side by side (+
> examples).
+1 for having a wiki page. This might be useful for some collaborative
editing. Although for sharing code snippets using simple gists [1]
might be simpler. There is also a wiki functionality on github [2].
Emmanuel/Hardy: Could you enable that for the beanvalidation repository?
I am not against enabling the wiki but we have already several tools at our disposal and I
wonder if adding a new will be beneficial or detrimental.
I would like us to try to use the website as a pseudo-wiki. Granted, it is not as
immediate as a wiki but this model might work. If this turns out to fail, we can fall back
to GitHub's wiki.
3:22 p.m.
On Fri, 16 Sep 2011 15:15:10 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> +1 for having a wiki page. This might be useful for some
collaborative
> editing. Although for sharing code snippets using simple gists [1]
> might be simpler. There is also a wiki functionality on github [2].
>
> Emmanuel/Hardy: Could you enable that for the beanvalidation repository?
I am not against enabling the wiki but we have already several tools at
our disposal and I wonder if adding a new will be beneficial or
detrimental.
I would like us to try to use the website as a pseudo-wiki. Granted, it
is not as immediate as a wiki but this model might work. If this turns
out to fail, we can fall back to GitHub's wiki.
So how would that work? We checkout the site and make changes locally and
create
pull requests?
--Hardy
4:25 p.m.
New subject: Wiki (Was Re: Method level validation)
On 16 sept. 2011, at 15:22, Hardy Ferentschik wrote:
On Fri, 16 Sep 2011 15:15:10 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>> +1 for having a wiki page. This might be useful for some collaborative
>> editing. Although for sharing code snippets using simple gists [1]
>> might be simpler. There is also a wiki functionality on github [2].
>>
>> Emmanuel/Hardy: Could you enable that for the beanvalidation repository?
>
> I am not against enabling the wiki but we have already several tools at
> our disposal and I wonder if adding a new will be beneficial or
> detrimental.
> I would like us to try to use the website as a pseudo-wiki. Granted, it
> is not as immediate as a wiki but this model might work. If this turns
> out to fail, we can fall back to GitHub's wiki.
So how would that work? We checkout the site and make changes locally and
create
pull requests?
Good point.
I think the pull request approach will not work very well.
One alternative is to give r/w access to whoever wants in this group if you promise me to
rebase as opposed to merge and keep commits focused and to the point :)
People interested in the experiment, give me your github login and I will add you to the
read write group.
Note: the website is usually updated within 2 mins of a push to GitHub.
4:59 p.m.
New subject: Wiki (Was Re: Method level validation)
On Fri, 16 Sep 2011 16:25:05 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
Note: the website is usually updated within 2 mins of a push to
GitHub.
That would have been my next question :-)
Maybe you could setup some initial page or place under which we put the
wiki style content/discussions
--Hardy
5:46 p.m.
New subject: Wiki (Was Re: Method level validation)
On 16 sept. 2011, at 16:59, Hardy Ferentschik wrote:
On Fri, 16 Sep 2011 16:25:05 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> Note: the website is usually updated within 2 mins of a push to GitHub.
That would have been my next question :-)
Maybe you could setup some initial page or place under which we put the
wiki style content/discussions
I was thinking something like /proposal/ unless we want to use /wiki/
the index.md page simply listing the current proposals or discussions.
5:49 p.m.
New subject: Wiki (Was Re: Method level validation)
On 16 sept. 2011, at 16:59, Hardy Ferentschik wrote:
On Fri, 16 Sep 2011 16:25:05 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> Note: the website is usually updated within 2 mins of a push to GitHub.
That would have been my next question :-)
Maybe you could setup some initial page or place under which we put the
wiki style content/discussions
--Hardy
By the way, I have remove the production branch, master is now what goes live. It was
simply cumbersome.
To write code in markdown and if you have @ muse the following approach
<pre>public class MyClass {
@NotNull String my Property;
</pre>
There is a small bug in the markdown engine I use that swallows the @ character :(
http://beanvalidation.org/news/2011/09/16/method-level-validation/ is an example.
3:15 p.m.
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
1:30 p.m.
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
10:36 a.m.
Yes the link between the marker annotation and the main annotation is not obvious to the
code reader. I was thinking about an annotation on the marker annotation itself but
that's a bit hidden to the user.
On 25 sept. 2011, at 13:30, Gunnar Morling wrote:
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;
> @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
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:15 p.m.
On 7 sept. 2011, at 22:55, Sebastian Thomschke wrote:
OVal currently uses parameter names only for error reporting and not
to
provide cross-parameter validations. To express preconditions the user
is currently limited to work with an array containing the argument
values only:
@Pre("_args[0] != _args[1]", lang="groovy")
void myMethod(String uniqueValue, String anotherUniqueValue) {
// whatever....
}
Do you remember why you have this limitation?
9:56 p.m.
The reason OVal only uses named parameters when rendering error messages
is, that there is no reliable way to determine the parameter names in
every possible situation. Now if you think of reusing business model
classes between projects (e.g. reusing precompiled JARs) depending on
which parameter resolver you use different parameter names are resolved
this might break validation.
Therefore as long as Java does not provide a
java.lang.reflect.Method.getParameterNames() method I personally would
not rely on parameter names in validation rules - except we provide
something like a parameter-level @Named("parameter-name") annotation
which is mandatory in cases where you want to reference parameters by name.
Seb
On 16.09.2011 15:15, Emmanuel Bernard wrote:
On 7 sept. 2011, at 22:55, Sebastian Thomschke wrote:
> OVal currently uses parameter names only for error reporting and not to
> provide cross-parameter validations. To express preconditions the user
> is currently limited to work with an array containing the argument
> values only:
> @Pre("_args[0] != _args[1]", lang="groovy")
> void myMethod(String uniqueValue, String anotherUniqueValue) {
> // whatever....
> }
Do you remember why you have this limitation?
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:29 p.m.
Answers inline.
--Gunnar
2011/9/7 Gerhard Petracek <gerhard.petracek(a)gmail.com>:
hi,
@MethodValidator
+1 for the concept in general
however, if there isn't a reason for using T object compared to Class<T>
clazz (see [1]) as parameter, i would prefer Class<T>.
In HV we're using the passed object as root bean in the resulting
ConstraintViolation. How is that in Apache Validation, is the root
bean null in that case? Btw. how are you handling property path's for
method validation? In HV we've path's like this:
"CustomerRepository#persistCustomer(arg0).address.city".
@BeanDescriptor (renaming it to TypeDescriptor)
it's a type-safe change - but still -1
Yepp, that's probably not worth a breaking change.
@named parameters:
(for the spec.) i don't like the idea to re-use @Named for it (the package
javax.inject and therefore the dependency in general look strange from the
perspective of bv)
I understand these concerns. What would you prefer for naming? Maybe
we could have an own annotation?
imo we should re-visit cross-field validation. a solution for it
might
influence this topic as well (to keep it consistent).
regards,
gerhard
[1]
https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/bval-...
2011/9/6 Gunnar Morling <gunnar.morling(a)googlemail.com>
>
> Hi,
>
> > Gunnar, could to take the lead on the Hibernate Validator version? You
> > know this area best.
>
> Sure. What we have in HV [1], [2] is pretty much based on appendix C
> of BV 1.0 [3]. More specifically that is:
>
> * IF MethodValidator:
>
> public interface MethodValidator {
>
> <T> Set<MethodConstraintViolation<T>> validateParameter(T
object,
> Method method, Object parameterValue, int parameterIndex, Class<?>...
> groups);
>
> <T> Set<MethodConstraintViolation<T>>
validateAllParameters(T
> object,
> Method method, Object[] parameterValues, Class<?>... groups);
>
> <T> Set<MethodConstraintViolation<T>> validateReturnValue(T
object,
> Method method, Object returnValue, Class<?>... groups);
>
> TypeDescriptor getConstraintsForType(Class<?> clazz);
> }
>
> In BV these methods should go into javax.validation.Validator (plus
> validateConstructorParameters or similar).
>
> * IF MethodConstraintViolation which extends ConstraintViolation by
> adding getMethod(), getParameterIndex() etc. to specify the source of
> a violation.
>
> * MethodConstraintViolationException, wrapping a set of
> MethodConstraintViolations and to be thrown by integrators of the
> method validation feature.
>
> * Extension to the constraint meta data API based on IF TypeDescriptor:
>
> public interface TypeDescriptor extends ElementDescriptor {
>
> boolean isTypeConstrained();
>
> Set<MethodDescriptor> getConstrainedMethods();
>
> MethodDescriptor getConstraintsForMethod(String methodName,
> Class<?>... parameterTypes);
>
> BeanDescriptor getBeanDescriptor();
> }
>
> In BV 1.1 this should be merged with BeanDescriptor (which in turn
> should be renamed to TypeDescriptor IMO as it isn't restricted to
> JavaBeans any more).
>
> * Extension to the programmatic API [4] allowing to specify method
> constraints programmatically like this:
>
> ConstraintMapping mapping = new ConstraintMapping();
> mapping.type( Car.class )
> .method( "drive", String.class, Integer.class )
> .parameter( 0 )
> .constraint( new NotNullDef() )
> .constraint( new MinDef().value ( 1 ) )
> .returnValue()
> .valid();
>
> HibernateValidatorConfiguration config = Validation.byProvider(
> HibernateValidator.class ).configure();
> config.addMapping( mapping );
> Validator validator = config.buildValidatorFactory().getValidator();
>
> What we don't have:
>
> * constructor validation
>
> * cross-parameter validation as discussed in BV-232.
>
> * parameter constraints may only be specified at the "lowest version"
> of an overridden method, see [5]. Though I don't think that this
> restriction is really an issue.
>
> * ability to specify parameter names, see [6].
>
> @Hardy: Do see anything missing?
>
> --Gunnar
>
>
> [1] HV reference guide on method validation:
>
>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/val...
> [2] HV's method validation API:
>
>
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hiber...
> [3] BV 1.0, Appendix C:
> http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
> [4] HV's programmatic constraint API:
>
>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
> [5] Using method constraints in type hierarchies:
>
>
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin...
> [6] Specifying parameter names: https://hibernate.onjira.com/browse/HV-409
>
>
> 2011/9/6 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> > While we still decide what to do in which order, I'd like to start
> > thinking about method level validation in parallel.
> >
> > Probably the biggest feature for this new round (
> > http://beanvalidation.org/roadmap/ ) is method level validation.
> >
> > ## Goal
> >
> > Offer the ability to:
> >
> > - annotate method and constructor parameters and return values with Bean
> > Validation constraints.
> > - provide validation methods to validate a method / constructor given a
> > set of parameters
> >
> > This set of methods will be used by framework controlling the method
> > execution cycle (CDI, JAX-RS, aspect oriented frameworks etc).
> >
> > https://hibernate.onjira.com/browse/BVAL-232
> >
> > We need to explore this feature to clarify what we want to support, how
> > we want to support it, how it integrates with Bean Validation 1.0.
> >
> > ## Usefulness
> >
> > This method will be useful to various other specifications including CDI
> > and JAX-RS. That's why I'd like to stabilize this feature as early as
> > possible.
> >
> > ## Proposals
> >
> > Hibernate Validator has an implementation of such feature and I am sure
> > OVal, Apache Bean Validation and others have something similar. Let's start
> > with describing what we have and start the discussion from here.
> >
> > Gunnar, could to take the lead on the Hibernate Validator version? You
> > know this area best.
> >
> > Emmanuel
> > _______________________________________________
> > 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
4:22 p.m.
Thanks for the various feedback.
Here are my thoughts.
We can't rename BeanDescriptor to TypeDescriptor as it would break backward
compatibility. Even then, I am not convinced that TypeDescriptor is a better name for
BeanDescriptor.
I agree we could revisit cross field validation to see if we could converge on a better
approach, I've opened https://hibernate.onjira.com/browse/BVAL-240
On named parameters we have three strategies I think:
- not address the problem at all and use positional parameters to see what comes up JDK
8's hat (named parameters might not be represented as strings but rather as a typed
object)
- not address the problem in the specification but leave the API open enough for a
provider to offer a named parameter friendly API
- address the problem within the spec (the interface approach seems elegant) hoping for
the named parameter to be represented as a String in JDK 8
I tend to like param0, param1 etc rather than arg0, arg1 but that's aesthetic.
One part we have not addressed is how constraints are declared on the method. HV works
that way (Gunnar, Hardy correct me if I side track).
Constraints on parameters whose type is a subtype of the accepted types by the constraint
are declared directly on the parameter
void doHarm(@NotEmpty String kittenName);
Constrains on parameters whose type is a constrained bean needs an annotation accepting
the targeted groups. It was proposed to use @Valid for such case but recent discussions
brought that back on the drawing board.
https://hibernate.onjira.com/browse/BVAL-208?focusedCommentId=43533#comme...
There are a few notions floating around @Valid
1. cascade validation to nested beans
2. translate the validation of group A from the owning bean to validation of the group B
on the nested bean (see <https://hibernate.onjira.com/browse/BVAL-208>)
3. define the group to validate in a method level validation
About 3., I wonder if this should be part of Bean Validation or be part of the
interception framework. In other words:
* should it be an annotation provided / proposed by Bean Validation and recognized by
interception techs like CDI, @Inject, Spring, AspectJ etc
* should each interception tech provide its own annotation to specify the targeted
group(s)
Emmanuel
On 6 sept. 2011, at 12:16, Emmanuel Bernard wrote:
While we still decide what to do in which order, I'd like to
start thinking about method level validation in parallel.
Probably the biggest feature for this new round ( http://beanvalidation.org/roadmap/ ) is
method level validation.
## Goal
Offer the ability to:
- annotate method and constructor parameters and return values with Bean Validation
constraints.
- provide validation methods to validate a method / constructor given a set of
parameters
This set of methods will be used by framework controlling the method execution cycle
(CDI, JAX-RS, aspect oriented frameworks etc).
https://hibernate.onjira.com/browse/BVAL-232
We need to explore this feature to clarify what we want to support, how we want to
support it, how it integrates with Bean Validation 1.0.
## Usefulness
This method will be useful to various other specifications including CDI and JAX-RS.
That's why I'd like to stabilize this feature as early as possible.
## Proposals
Hibernate Validator has an implementation of such feature and I am sure OVal, Apache Bean
Validation and others have something similar. Let's start with describing what we have
and start the discussion from here.
Gunnar, could to take the lead on the Hibernate Validator version? You know this area
best.
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
1:07 p.m.
Hi,
I thought it might be a good idea to provide some structure for the
discussion and hence created
https://hibernate.onjira.com/browse/BVAL-241 as umbrella issue for
method validation.
For the different aspects discussed so far I created the following sub-tasks:
BVAL-241
|
|- BVAL-245: Define how method constraints are declared at parameters
and return values
|
|- BVAL-244: Extend Validator API with methods for method validation
|
|- BVAL-242: Extend the meta-data API to represent method-level constraints
|
|- BVAL-232: Support cross-parameter constraints (was "Support
Method-Level constraint declaration")
|
|- BVAL-243: Provide a means for specifying method parameter names
|
|- BVAL-246: Create TCK tests for method validation
IMO it would be a good idea to discuss the details at the related issues. WDYT?
--Gunnar
2011/9/16 Emmanuel Bernard <emmanuel(a)hibernate.org>:
Thanks for the various feedback.
Here are my thoughts.
We can't rename BeanDescriptor to TypeDescriptor as it would break backward
compatibility. Even then, I am not convinced that TypeDescriptor is a better name for
BeanDescriptor.
I agree we could revisit cross field validation to see if we could converge on a better
approach, I've opened https://hibernate.onjira.com/browse/BVAL-240
On named parameters we have three strategies I think:
- not address the problem at all and use positional parameters to see what comes up JDK
8's hat (named parameters might not be represented as strings but rather as a typed
object)
- not address the problem in the specification but leave the API open enough for a
provider to offer a named parameter friendly API
- address the problem within the spec (the interface approach seems elegant) hoping for
the named parameter to be represented as a String in JDK 8
I tend to like param0, param1 etc rather than arg0, arg1 but that's aesthetic.
One part we have not addressed is how constraints are declared on the method. HV works
that way (Gunnar, Hardy correct me if I side track).
Constraints on parameters whose type is a subtype of the accepted types by the constraint
are declared directly on the parameter
void doHarm(@NotEmpty String kittenName);
Constrains on parameters whose type is a constrained bean needs an annotation accepting
the targeted groups. It was proposed to use @Valid for such case but recent discussions
brought that back on the drawing board.
https://hibernate.onjira.com/browse/BVAL-208?focusedCommentId=43533#comme...
There are a few notions floating around @Valid
1. cascade validation to nested beans
2. translate the validation of group A from the owning bean to validation of the group B
on the nested bean (see <https://hibernate.onjira.com/browse/BVAL-208>)
3. define the group to validate in a method level validation
About 3., I wonder if this should be part of Bean Validation or be part of the
interception framework. In other words:
* should it be an annotation provided / proposed by Bean Validation and recognized by
interception techs like CDI, @Inject, Spring, AspectJ etc
* should each interception tech provide its own annotation to specify the targeted
group(s)
Emmanuel
On 6 sept. 2011, at 12:16, Emmanuel Bernard wrote:
> While we still decide what to do in which order, I'd like to start thinking about
method level validation in parallel.
>
> Probably the biggest feature for this new round ( http://beanvalidation.org/roadmap/
) is method level validation.
>
> ## Goal
>
> Offer the ability to:
>
> - annotate method and constructor parameters and return values with Bean Validation
constraints.
> - provide validation methods to validate a method / constructor given a set of
parameters
>
> This set of methods will be used by framework controlling the method execution cycle
(CDI, JAX-RS, aspect oriented frameworks etc).
>
> https://hibernate.onjira.com/browse/BVAL-232
>
> We need to explore this feature to clarify what we want to support, how we want to
support it, how it integrates with Bean Validation 1.0.
>
> ## Usefulness
>
> This method will be useful to various other specifications including CDI and JAX-RS.
That's why I'd like to stabilize this feature as early as possible.
>
> ## Proposals
>
> Hibernate Validator has an implementation of such feature and I am sure OVal, Apache
Bean Validation and others have something similar. Let's start with describing what we
have and start the discussion from here.
>
> Gunnar, could to take the lead on the Hibernate Validator version? You know this area
best.
>
> Emmanuel
> _______________________________________________
> 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
10:34 a.m.
Thanks,
I think what works best is an initial discussion by email followed by a proposal (spec
change) and refinements that can be discussed either on this mailing list or on the
specific BVAL elements.
I must admit following all BVAL changes is not as easy as it should and I expect many here
will only follow this mailing list. So fine grained discussions on BVAL elements is good
as long as they are retrofitted into the proposal.
On 25 sept. 2011, at 13:07, Gunnar Morling wrote:
Hi,
I thought it might be a good idea to provide some structure for the
discussion and hence created
https://hibernate.onjira.com/browse/BVAL-241 as umbrella issue for
method validation.
For the different aspects discussed so far I created the following sub-tasks:
BVAL-241
|
|- BVAL-245: Define how method constraints are declared at parameters
and return values
|
|- BVAL-244: Extend Validator API with methods for method validation
|
|- BVAL-242: Extend the meta-data API to represent method-level constraints
|
|- BVAL-232: Support cross-parameter constraints (was "Support
Method-Level constraint declaration")
|
|- BVAL-243: Provide a means for specifying method parameter names
|
|- BVAL-246: Create TCK tests for method validation
IMO it would be a good idea to discuss the details at the related issues. WDYT?
--Gunnar
2011/9/16 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> Thanks for the various feedback.
> Here are my thoughts.
>
> We can't rename BeanDescriptor to TypeDescriptor as it would break backward
compatibility. Even then, I am not convinced that TypeDescriptor is a better name for
BeanDescriptor.
>
> I agree we could revisit cross field validation to see if we could converge on a
better approach, I've opened https://hibernate.onjira.com/browse/BVAL-240
>
> On named parameters we have three strategies I think:
> - not address the problem at all and use positional parameters to see what comes up
JDK 8's hat (named parameters might not be represented as strings but rather as a
typed object)
> - not address the problem in the specification but leave the API open enough for a
provider to offer a named parameter friendly API
> - address the problem within the spec (the interface approach seems elegant) hoping
for the named parameter to be represented as a String in JDK 8
>
> I tend to like param0, param1 etc rather than arg0, arg1 but that's aesthetic.
>
> One part we have not addressed is how constraints are declared on the method. HV
works that way (Gunnar, Hardy correct me if I side track).
>
> Constraints on parameters whose type is a subtype of the accepted types by the
constraint are declared directly on the parameter
>
> void doHarm(@NotEmpty String kittenName);
>
> Constrains on parameters whose type is a constrained bean needs an annotation
accepting the targeted groups. It was proposed to use @Valid for such case but recent
discussions brought that back on the drawing board.
> https://hibernate.onjira.com/browse/BVAL-208?focusedCommentId=43533#comme...
>
> There are a few notions floating around @Valid
>
> 1. cascade validation to nested beans
> 2. translate the validation of group A from the owning bean to validation of the
group B on the nested bean (see <https://hibernate.onjira.com/browse/BVAL-208>)
> 3. define the group to validate in a method level validation
>
> About 3., I wonder if this should be part of Bean Validation or be part of the
interception framework. In other words:
>
> * should it be an annotation provided / proposed by Bean Validation and recognized by
interception techs like CDI, @Inject, Spring, AspectJ etc
> * should each interception tech provide its own annotation to specify the targeted
group(s)
>
> Emmanuel
>
> On 6 sept. 2011, at 12:16, Emmanuel Bernard wrote:
>
>> While we still decide what to do in which order, I'd like to start thinking
about method level validation in parallel.
>>
>> Probably the biggest feature for this new round (
http://beanvalidation.org/roadmap/ ) is method level validation.
>>
>> ## Goal
>>
>> Offer the ability to:
>>
>> - annotate method and constructor parameters and return values with Bean
Validation constraints.
>> - provide validation methods to validate a method / constructor given a set of
parameters
>>
>> This set of methods will be used by framework controlling the method execution
cycle (CDI, JAX-RS, aspect oriented frameworks etc).
>>
>> https://hibernate.onjira.com/browse/BVAL-232
>>
>> We need to explore this feature to clarify what we want to support, how we want
to support it, how it integrates with Bean Validation 1.0.
>>
>> ## Usefulness
>>
>> This method will be useful to various other specifications including CDI and
JAX-RS. That's why I'd like to stabilize this feature as early as possible.
>>
>> ## Proposals
>>
>> Hibernate Validator has an implementation of such feature and I am sure OVal,
Apache Bean Validation and others have something similar. Let's start with describing
what we have and start the discussion from here.
>>
>> Gunnar, could to take the lead on the Hibernate Validator version? You know this
area best.
>>
>> Emmanuel
>> _______________________________________________
>> 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
4595
days inactive
4615
days old
beanvalidation-dev@lists.jboss.org
23 comments
6 participants
participants (6)
-
Emmanuel Bernard -
Gerhard Petracek -
Gunnar Morling -
Hardy Ferentschik -
Rich Midwinter -
Sebastian Thomschke