详解Spring注解@Validated 失效分析
作者：Jerry_Chan
这篇文章主要介绍了Spring注解@Validated失效分析，文中有详细代码示例讲解了@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;
}
}小结
1、在普通 Bean 中如果要通过注解的方式使用 hibernate-validator 进行校验的话，需要在类上添加 @Validated 注解，同时在方法上添加 @Valid 注解。或者也可以直接使用 @NotNull 等注解。
2、普通 Bean 使用 @Validated 是通过动态代理完成的。具体的拦截器便是他 MethodValidationInterceptor。
3、Controller 层之所以能 @Validated 和 @Valid 二选一，是因为校验的是参数本身，而普通 Bean 校验的是 Bean 本身。
4、至此，相信大家就不会没配置好 @Validated 导致失效了。
到此这篇关于详解Spring注解@Validated 失效分析的文章就介绍到这了,更多相关Spring注解@Validated失效内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！