这篇文章主要介绍“Spring注解@Validated失效怎么解决”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“Spring注解@Validated失效怎么解决”文章能帮助大家解决问题。
Controller 中使用 @Validated
@Validated 注解的作用这里就不多做介绍了，具体用法在网上应该有不少。
在之前使用 MVC 架构编码时，通常是将 @Validated 注解或者 @Valid 配置在 Controller 的方法中，如下代码所示：
@PostMapping("common/set")
public Response<?> setCommonSetting(@RequestBody @Validated SetCommonSettingReqVO reqVO) {
//doSomeThings
return Response.success();
}所以在配置应用层校验时，就想当然的按照类似的写法：
public void addClueTrack(@Validated AddClueTrackCommand command) {
//doSomeThings
}结果可想而知，@Validated 注解并不生效。
@Validated 是怎么生效的？
竟然不生效，那么就开始分析原因。
首先可以很容易想到，竟然能在方法执行前就拦截进行校验，那么大概率是使用动态代理。就和 @Transactional 事务注解一样，底层都是基于 AOP 实现动态代理。
接下来为了印证这个想法，就是需要深入看看 Spring 实现的。通过 IDE 可以很方便看到有哪些地方引用了 @Validated 注解：
其中一个类名一下就引起了我的注意 MethodValidationPostProcessor，熟悉 Spring 的小伙伴应该知道，Spring 中有很多 BeanPostProcessor 用于扩展 Bean，Aop 便是基于此实现动态代理的。点进去一看，果不其然：
public class MethodValidationPostProcessor extends AbstractBeanFactoryAwareAdvisingPostProcessor
implements InitializingBean {
private Class<? extends Annotation> validatedAnnotationType = Validated.class;
@Nullable
private Validator validator;
//...
@Override
public void afterPropertiesSet() {
//创建切点
Pointcut pointcut = new AnnotationMatchingPointcut(this.validatedAnnotationType, true);
this.advisor = new DefaultPointcutAdvisor(pointcut, createMethodValidationAdvice(this.validator));
}
protected Advice createMethodValidationAdvice(@Nullable Validator validator) {
//创建拦截器
return (validator != null ? new MethodValidationInterceptor(validator) : new MethodValidationInterceptor());
}
}
public class AnnotationMatchingPointcut implements Pointcut {
private final ClassFilter classFilter;
private final MethodMatcher methodMatcher;
public AnnotationMatchingPointcut(Class<? extends Annotation> classAnnotationType, boolean checkInherited) {
//切点只针对类级别
this.classFilter = new AnnotationClassFilter(classAnnotationType, checkInherited);
this.methodMatcher = MethodMatcher.TRUE;
}
//...
}MethodValidationPostProcessor 中创建了一个切点，过滤类上添加了 @Validated 的 Bean，只要满足此条件，就会根据 MethodValidationInterceptor 生成对应的代理类。嗯，和 @Transactional 的实现原理差不多。
ok，看到这里我就在应用服务实现上添加了 @Validated 注解，那么此时注解生效了吗？哈哈，进度条还没过半呢????
理论上类上加上 @Validated 注解，应该会生成动态代理类的，竟然没成功进行参数校验，我能想到的原因有二：
1. MethodValidationPostProcessor 没注入到 BeanFactory 中，所以没生成对应的代理类 2. MethodValidationInterceptor 对还有其他需要满足的条件，而目前还未满足
这里先剧透一下，答案是 2 ????
MethodValidationInterceptor需要满足什么条件
竟然答案是2，那这里就先讲一下 MethodValidationInterceptor，MethodValidationPostProcessor 是怎么注册到容器的咱们后面再来讲。
ExecutableValidatorpublic class MethodValidationInterceptor implements MethodInterceptor {
private final Validator validator;
@Override
@Nullable
public Object invoke(MethodInvocation invocation) throws Throwable {
// Standard Bean Validation 1.1 API
ExecutableValidator execVal = this.validator.forExecutables();
Method methodToValidate = invocation.getMethod();
Set<ConstraintViolation<Object>> result;
//获取类本身的实例（非代理类），请记住这里，这里就是和 Controller 最大的区别
Object target = invocation.getThis();
Assert.state(target != null, "Target must not be null");
try {
//执行参数校验，校验的是当前类，也就是说校验的是 Bean 对应的类
result = execVal.validateParameters(target, methodToValidate, invocation.getArguments(), groups);
}
catch (IllegalArgumentException ex) {
//doSomeThings
}
if (!result.isEmpty()) {
throw new ConstraintViolationException(result);
}
//执行方法
Object returnValue = invocation.proceed();
//校验返回值
result = execVal.validateReturnValue(target, methodToValidate, returnValue, groups);
if (!result.isEmpty()) {
throw new ConstraintViolationException(result);
}
return returnValue;
}
}接下来就要看看 ExecutableValidator.validateParameters 这个方法是如何实现的，为了方便阅读，这里我只保留了部分核心代码。根据包名我们大概也能猜到 ExecutableValidator.validateParameters 是 hibernate-validator 包提供的方法，而 @Validated 注解是由 Spring 提供的，所以不生效也就正常了。接下来我们继续往下走，我这里只贴部分核心的代码，中间的栈路径可以根据以下这个路径往下走：
/**
* --> org.hibernate.validator.internal.engine.ValidatorImpl#validateParameters
* --> org.hibernate.validator.internal.metadata.BeanMetaDataManager#getBeanMetaData
* --> org.hibernate.validator.internal.metadata.BeanMetaDataManagerImpl#createBeanMetaData
* --> org.hibernate.validator.internal.metadata.BeanMetaDataManagerImpl#getBeanConfigurationForHierarchy
* --> org.hibernate.validator.internal.metadata.provider.MetaDataProvider#getBeanConfiguration
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#retrieveBeanConfiguration
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#getFieldMetaData
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#findPropertyMetaData
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#findConstraints
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#findCascadingMetaData
* <-- ...
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#getMethodMetaData
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#getConstructorMetaData
* --> org.hibernate.validator.internal.metadata.provider.AnnotationMetaDataProvider#getClassLevelConstraints
* <-- ...
* --> org.hibernate.validator.internal.metadata.aggregated.BeanMetaData#hasConstraints
* --> org.hibernate.validator.internal.engine.ValidatorImpl#validateParametersInContext
*
*/
public class ValidatorImpl implements Validator, ExecutableValidator {
@Override
public final <T> Set<ConstraintViolation<T>> validateValue(Class<T> beanType, String propertyName, Object value, Class<?>... groups) {
Contracts.assertNotNull( beanType, MESSAGES.beanTypeCannotBeNull() );
sanityCheckPropertyPath( propertyName );
sanityCheckGroups( groups );
//获取 bean 及其父类、超类的
BeanMetaData<T> rootBeanMetaData = beanMetaDataManager.getBeanMetaData( beanType );
//判断该 bean 是否有约束
if ( !rootBeanMetaData.hasConstraints() ) {
return Collections.emptySet();
}
PathImpl propertyPath = PathImpl.createPathFromString( propertyName );
BaseBeanValidationContext<T> validationContext = getValidationContextBuilder().forValidateValue( beanType, rootBeanMetaData, propertyPath );
ValidationOrder validationOrder = determineGroupValidationOrder( groups );
//校验参数
return validateValueInContext(validationContext, value, propertyPath, validationOrder);
}
//...
}当我调试到 rootBeanMetaData.hasConstraints() 时，判断没有约束，然后就直接返回了没有进行参数校验。我就想说看看是如何判断 Bean 是否有约束的，于是就返回上层进入 beanMetaDataManager.getBeanMetaData 中看，结果发现里面的代码有够复杂的????
public class AnnotationMetaDataProvider implements MetaDataProvider {
//获取类上所有的约束条件
private <T> BeanConfiguration<T> retrieveBeanConfiguration(Class<T> beanClass) {
//获取字段上的约束条件
Set<ConstrainedElement> constrainedElements = getFieldMetaData( beanClass );
//获取方法上的约束条件（包括参数、返回值）
constrainedElements.addAll( getMethodMetaData( beanClass ) );
//获取构造函数
constrainedElements.addAll( getConstructorMetaData( beanClass ) );
//获取类上的约束条件
Set<MetaConstraint<?>> classLevelConstraints = getClassLevelConstraints( beanClass );
if ( !classLevelConstraints.isEmpty() ) {
ConstrainedType classLevelMetaData =
new ConstrainedType(ConfigurationSource.ANNOTATION, beanClass, classLevelConstraints);
constrainedElements.add( classLevelMetaData );
}
return new BeanConfiguration<>(ConfigurationSource.ANNOTATION, beanClass, constrainedElements, getDefaultGroupSequence( beanClass ), getDefaultGroupSequenceProvider( beanClass ));
}
//查找约束注解
protected <A extends Annotation> List<ConstraintDescriptorImpl<?>> findConstraintAnnotations(Constrainable constrainable, A annotation, ConstraintLocationKind type) {
//如果包含 "jdk.internal" and "java" 下的注解，则直接不进行校验
if ( constraintCreationContext.getConstraintHelper().isJdkAnnotation( annotation.annotationType() ) ) {
return Collections.emptyList();
}
List<Annotation> constraints = newArrayList();
Class<? extends Annotation> annotationType = annotation.annotationType();
//判断是否有约束条件，也就我们经常配置的 @NotNull，@Min 这类注解
if ( constraintCreationContext.getConstraintHelper().isConstraintAnnotation( annotationType ) ) {
constraints.add( annotation );
}
//这个没用过，暂时跳过
else if ( constraintCreationContext.getConstraintHelper().isMultiValueConstraint( annotationType ) ) {
constraints.addAll( constraintCreationContext.getConstraintHelper().getConstraintsFromMultiValueConstraint( annotation ) );
}
return constraints.stream()
.map( c -> buildConstraintDescriptor( constrainable, c, type ) )
.collect( Collectors.toList() );
}
//构建级联元数据构造器，也就是我们常用的 @Valid，在 Bean 中如果我们要对对象属性进行校验，
//需要在该属性上添加 @Valid，此处便是如此
private CascadingMetaDataBuilder getCascadingMetaData(JavaBeanAnnotatedElement annotatedElement, Map<TypeVariable<?>, CascadingMetaDataBuilder> containerElementTypesCascadingMetaData) {
return CascadingMetaDataBuilder.annotatedObject( annotatedElement.getType(), annotatedElement.isAnnotationPresent( Valid.class ),
containerElementTypesCascadingMetaData, getGroupConversions( annotatedElement.getAnnotatedType() ) );
}
}顺着上面的栈路径一直往下走，最终发现最核心的几个方法是 getFieldMetaData、getMethodMetaData、getConstructorMetaData、getClassLevelConstraints，这个几方法都是用于获取约束和级联元数据。那么里面到底是怎么获取约束元数据的呢，咱继续往里钻，可以看到最终调用了 findConstraintAnnotations 获取约束元数据，也就是我们平时用到的 @NotNull，@Min 等注解，通过 getCascadingMetaData 获取级联元数据，也就是 @Valid 注解。看到这，是不是很容易就能想到，知道我加上 @Valid 就能成功校验了呢？
于是我尝试了一波，果然没问题。嗯~ 长见识了????。由于时间有限，ValidatorImpl.validateParametersInContext() 方法我就没有深入进去看了。感兴趣的小伙伴可以自行去看看！！????
那么 Controller 为啥直接添加@Validated 或者 @Valid 就可以呢？
明白了在应用服务实现，准确的说应该是普通 Bean 中应该怎么配置之 @Validated 和 @Valid 使其生效之后，我就很好奇为啥 Controller 只需要单独在方法上配置 @Validated 或者 @Valid 就能成功校验呢？
还记得上面通过 IDE 查看应用 @Validated 注解的类时，我们发现了 MethodValidationPostProcessor，还有另外几个类一看就很像 Controller 参数解析相关的类：
我在这几个类上各打了一个断点，最终进入的是 AbstractMessageConverterMethodArgumentResolver。
ok，那就看看他是怎么实现的，这里只贴了很参数校验相关的方法：
public abstract class AbstractMessageConverterMethodArgumentResolver implements HandlerMethodArgumentResolver {
protected void validateIfApplicable(WebDataBinder binder, MethodParameter parameter) {
Annotation[] annotations = parameter.getParameterAnnotations();
for (Annotation ann : annotations) {
//获取分组信息
Object[] validationHints = ValidationAnnotationUtils.determineValidationHints(ann);
if (validationHints != null) {
//进行校验
binder.validate(validationHints);
break;
}
}
}
}
public abstract class ValidationAnnotationUtils {
@Nullable
public static Object[] determineValidationHints(Annotation ann) {
Class<? extends Annotation> annotationType = ann.annotationType();
String annotationName = annotationType.getName();
//如果是 @valid 注解直接返回一个空数组
if ("javax.validation.Valid".equals(annotationName)) {
return EMPTY_OBJECT_ARRAY;
}
//如果是 @validated 则返回其分组信息
Validated validatedAnn = AnnotationUtils.getAnnotation(ann, Validated.class);
if (validatedAnn != null) {
Object hints = validatedAnn.value();
return convertValidationHints(hints);
}
if (annotationType.getSimpleName().startsWith("Valid")) {
Object hints = AnnotationUtils.getValue(ann);
return convertValidationHints(hints);
}
return null;
}
}
public class DataBinder implements PropertyEditorRegistry, TypeConverter {
public void validate(Object... validationHints) {
//此处是关键所在，这里获取的是参数！！！和普通的 Bean 获取到的却是 Bean 本身
Object target = getTarget();
Assert.state(target != null, "No target to validate");
BindingResult bindingResult = getBindingResult();
// Call each validator with the same binding result
for (Validator validator : getValidators()) {
if (!ObjectUtils.isEmpty(validationHints) && validator instanceof SmartValidator) {
((SmartValidator) validator).validate(target, bindingResult, validationHints);
}
else if (validator != null) {
validator.validate(target, bindingResult);
}
}
}
}可以看到，对于 Controller 不论是直接在参数上加上 @Validated 或者 @Valid 注解，都会进入到校验方法，而且校验的就是参数！！！而 Bean 校验的却是 Bean 本身！！！
MethodValidationPostProcessor 和 AbstractMessageConverterMethodArgumentResolver 是怎么被注册到 BeanFactory 的？
明白了 @Validated 的拦截实现的原理后，那么就只剩最后一个问题了，MethodValidationPostProcessor 和 AbstractMessageConverterMethodArgumentResolver 是怎么被注册到 BeanFactory 的。
其实不用看源码大概有也能猜到是 Spring Boot 自动装配的。为了印证一下，我还是贴一下源码：
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(ExecutableValidator.class)
@ConditionalOnResource(resources = "classpath:META-INF/services/javax.validation.spi.ValidationProvider")
@Import(PrimaryDefaultValidatorPostProcessor.class)
public class ValidationAutoConfiguration {
//...
@Bean
@ConditionalOnMissingBean
public static MethodValidationPostProcessor methodValidationPostProcessor(Environment environment, @Lazy Validator validator, ObjectProvider<MethodValidationExcludeFilter> excludeFilters) {
FilteredMethodValidationPostProcessor processor = new FilteredMethodValidationPostProcessor(excludeFilters.orderedStream());
boolean proxyTargetClass = environment.getProperty("spring.aop.proxy-target-class", Boolean.class, true);
processor.setProxyTargetClass(proxyTargetClass);
processor.setValidator(validator);
return processor;
}
}另外就是 AbstractMessageConverterMethodArgumentResolver 的几个实现类，均由 RequestMappingHandlerAdapter 实例化，而 RequestMappingHandlerAdapter 大家知道有 WebMvcAutoConfiguration 自动装配，时间原因，这就不看了。
public class RequestMappingHandlerAdapter extends AbstractHandlerMethodAdapter
implements BeanFactoryAware, InitializingBean {
private List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() {
List<HandlerMethodArgumentResolver> resolvers = new ArrayList<>(30);
// Annotation-based argument resolution
resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), false));
resolvers.add(new RequestParamMapMethodArgumentResolver());
resolvers.add(new PathVariableMethodArgumentResolver());
resolvers.add(new PathVariableMapMethodArgumentResolver());
resolvers.add(new MatrixVariableMethodArgumentResolver());
resolvers.add(new MatrixVariableMapMethodArgumentResolver());
resolvers.add(new ServletModelAttributeMethodProcessor(false));
resolvers.add(new RequestResponseBodyMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
resolvers.add(new RequestPartMethodArgumentResolver(getMessageConverters(), this.requestResponseBodyAdvice));
resolvers.add(new RequestHeaderMethodArgumentResolver(getBeanFactory()));
resolvers.add(new RequestHeaderMapMethodArgumentResolver());
resolvers.add(new ServletCookieValueMethodArgumentResolver(getBeanFactory()));
resolvers.add(new ExpressionValueMethodArgumentResolver(getBeanFactory()));
resolvers.add(new SessionAttributeMethodArgumentResolver());
resolvers.add(new RequestAttributeMethodArgumentResolver());
// Type-based argument resolution
resolvers.add(new ServletRequestMethodArgumentResolver());
resolvers.add(new ServletResponseMethodArgumentResolver());
resolvers.add(new HttpEntityMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
resolvers.add(new RedirectAttributesMethodArgumentResolver());
resolvers.add(new ModelMethodProcessor());
resolvers.add(new MapMethodProcessor());
resolvers.add(new ErrorsMethodArgumentResolver());
resolvers.add(new SessionStatusMethodArgumentResolver());
resolvers.add(new UriComponentsBuilderMethodArgumentResolver());
if (KotlinDetector.isKotlinPresent()) {
resolvers.add(new ContinuationHandlerMethodArgumentResolver());
}
// Custom arguments
if (getCustomArgumentResolvers() != null) {
resolvers.addAll(getCustomArgumentResolvers());
}
// Catch-all
resolvers.add(new PrincipalMethodArgumentResolver());
resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), true));
resolvers.add(new ServletModelAttributeMethodProcessor(true));
return resolvers;
}
}