[bv-dev] Method level validation
Sebastian Thomschke
sebastian.thomschke at web.de
Wed Sep 7 16:55:47 EDT 2011
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/oval/guard/ParameterNameResolverEnumerationImpl.java?view=markup
> simply returns enumerated names, e.g. param1, param2, param3
http://oval.svn.sourceforge.net/viewvc/oval/trunk/src/main/java/net/sf/oval/guard/ParameterNameResolverAspectJImpl.java?view=markup
> 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/oval/guard/ParameterNameResolverParanamerImpl.java?view=markup
> 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 at 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-jsr303/src/main/java/org/apache/bval/jsr303/extensions/MethodValidator.java
>>> 2011/9/6 Gunnar Morling<gunnar.morling at 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/validator-specifics.html#validator-customoptions-methodvalidation
>>>> [2] HV's method validation API:
>>>>
>>>> http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hibernate/validator/method/package-summary.html
>>>> [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_single/#programmaticapi
>>>> [5] Using method constraints in type hierarchies:
>>>>
>>>> http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#d0e3267
>>>> [6] Specifying parameter names:
>>>> https://hibernate.onjira.com/browse/HV-409
>>>>
>>>>
>>>> 2011/9/6 Emmanuel Bernard<emmanuel at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
More information about the beanvalidation-dev
mailing list