Support for javax.validation annotations on @PathVariable, @RequestHeader, @RequestParam [SPR-6380]

[spring-projects-issues]

Gerrit Brehmer opened SPR-6380 and commented

I thought this was already done, because support for controller method-parameter validation should be available for all parameters.

I there a reason to exclude annotated (@RequestParam, etc.) method parameters? Is it not possible to validate primitive values?

Simple example:
For Paging-Support i need two request parameters: "start" & "size". "start" must have a positive value or 0 and "size" must have a positive value and also a maximum set.

---

Affects: 3.0 RC2, 4.0.5

Issue Links:

• Support JSR 303 @Valid on @PathVariable [SPR-9840] #14473 Support JSR 303 @Valid on @PathVariable

75 votes, 80 watchers

[spring-projects-issues]

Juergen Hoeller commented

The problem here is that JSR-303 is only really defined for bean classes: The constraint annotations are expected to sit on the target model class. As a consequence, @Valid on a parameter with primitive type doesn't mean anything since the primitive type doesn't contain any constraint annotations... Instead, we'd have to support constraint annotations like @NotNull, @Size etc themselves as parameter annotations. We can certainly consider that.

Juergen

[spring-projects-issues]

Gerrit Brehmer commented

Thats sounds good, because I think same programming approach (by Annotations) for validation of input values is quite useful. Also, it would be great to be able to use SpEL-Expressions inside this validation annotations.

You could change(correct) the enhancement summary to "Support of javax.validation.*-Annotations for @PathVariable, etc.", because usage of @Valid is limited to bean classes.

[spring-projects-issues]

Roel van Dijk commented

And also: the JSR-303 @Valid annotation cannot be used on method parameters:

@Target(value={METHOD,FIELD})
@Retention(value=RUNTIME)
public @interface Valid ..

The current RC2 documentation (section 5.7.4.1) still uses this as an example, but that wouldn't work, right?

[spring-projects-issues]

Juergen Hoeller commented

Well, in the published version of the JSR-303 API that we're using, @Valid looks as follows:

@Target({ METHOD, FIELD, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
public @interface Valid {
}

So it can be used on method parameters... Which version of the API are you looking at there?

Juergen

[spring-projects-issues]

Roel van Dijk commented

Ah sorry about that. I was looking at the version I had extracted locally, which is the CR1 version. I hadn't realized that the final spec was released and that different from CR1. The new spec looks great, thanks, and the example in the manual is valid.

[spring-projects-issues]

Andrew Ebaugh commented

I understand the limitation of validating beans vs "primitive" types, like String.
However, it currently does not appear to work for beans when using @PathVariable either.

I'd like to annotate a @Controller method like so:

@RequestMapping(value = "/user/{guid}", method = RequestMethod.GET)
public User getByGuid(@Valid @PathVariable GuidString guidString) {
}

I have already registered a converter from String->GuidString and a JSR-303 global validator that processes the GuidString validation annotations. But the validation does not appear to be done prior to invoking my handler method. It looks like the web data binder validation is only performed for method parameters annotated with @ModelAttribute.

I can see in the HandlerMethodInvoker.resolveHandlerArguments code that for this PathVariable parameter, the "validate" boolean is true because the @Valid annotation has been processed, but no validation logic is performed.

[spring-projects-issues]

Kenny MacLeod commented

Take also the scenario where you have a bound model object passed in as a @RequestParam (e.g. @RequestParam MyModel model). If MyModel is annotated with JSR-303 annotations, it should be simple to pass the MyModel instance through the validator (in HandlerMethodInvoker.resolveRequestParam.

[spring-projects-issues]

Gerrit Brehmer commented

Hibernate Validator added this functionality (MethodValidator) in version 4.2.0-BETA1 http://opensource.atlassian.com/projects/hibernate/browse/HV-347

[spring-projects-issues]

Thad West commented

" Instead, we'd have to support constraint annotations like @NotNull, @Size etc themselves as parameter annotations. We can certainly consider that."...yes please!

[spring-projects-issues]

Johan Kindgren commented

I've started to look into this feature, would it be okay to assume that "primitive" arguments are annotated with javax.validation-annotations? (More precisely, annotated with annotations that themselves are annotated with javax.validation.Constraint.)
"Complex" arguments (which internally are annotated with javax.validation-annotations) should be annotated with @Valid or @Validated?

I also assume that the solution can't reference classes/interfaces from javax.validation?

[spring-projects-issues]

Johan Kindgren commented

I was perhaps a bit enthusiastic about the solution. The upcoming release of Validation-api 1.1 could help a lot, but then again maybe it isn't possible to bump the validation-api version right away.

Another possible solution could be to use a bytecode modifier to create a class with the correct annotations, but that seems somewhat like a hack?

My attempted solution would add a "validate" method called from AbstractNamedValueMethodArgumentResolver.resolveArgument, seems like it could handle @RequestParameter, @RequestHeader and @PathVariable.

[spring-projects-issues]

Jan Held commented

Is this topic still on the possible roadmap? I have the same problem, and fixed it for my case. I think a similar solution that Johan Kindgren proposed. Nevertheless I would prefer if this will be supported as a standard spring feature, so I can remove my workaround an simply provide custom validation Annotations and Classes.

[spring-projects-issues]

Benjamin M commented

+1

[spring-projects-issues]

Rossen Stoyanchev commented

The underlying implementation for this, i.e. the ability to validate method parameters, has run into unexpected challenges. For a proper resolution unfortunately we'll have to revisit in 4.2, after #16519 is resolved (see comments there for further detail).

[spring-projects-issues]

roll tide commented

Is this still on roadmap?