liufeiyu1002
liufeiyu1002
原因就是 `ConstraintViolationImpl` 会发生序列化问题。我想到的解决办法 1. 消费者端引入 ValidationFilter 和 Validation 进行前置校验，非法请求直接在消费者端就拦截掉 (不需要开发 只需要消费者端引入就可以) 2. 官方在 Validation 校验发生异常的时候 提供一个可由用户自定义扩展的异常信息包装的处理  如图 可以调用扩展 (通过静态类配置 或者 是spi扩展)对异常信息进行包装，框架提供默认扩展为 ` new ValidationException(e.getMessage())` 即仅返回异常消息，用户可以针对自己的需求，对`ConstraintViolation` 中的信息进行二次封装成可序列化的类 例如:#10415 这种实现
> 原因就是 `ConstraintViolationImpl` 会发生序列化问题。我想到的解决办法 > > 1. 消费者端引入 ValidationFilter 和 Validation 进行前置校验，非法请求直接在消费者端就拦截掉 (不需要开发 只需要消费者端引入就可以) > 2. 官方在 Validation 校验发生异常的时候 提供一个可由用户自定义扩展的异常信息包装的处理 >  > 如图 可以调用扩展 (通过静态类配置 或者 是spi扩展)对异常信息进行包装，框架提供默认扩展为 ` new...
#10451 @AlbumenJ @wujun27
`ConstraintViolationImpl `不同版本字段不一样， 新版本新增了字段，如果单纯这么包装的话 意义不大，只是拿到了你认为的有效信息， 最起码新的结果要实现 `ConstraintViolation` 接口
`@DubboReference` 是按照属性名称注入 `spring` 容器中的，在`beanFactory`中是 属性名称 对应 `beanDefinition` 使用 `@Autowire ` 不会出现该错误 因为是 `byType` 注入按照实例类型查找的， `@Resource` 是 `byName` 按照属性名称注入，， 在查找的时候通过 属性名称 匹配，如果匹配到就会拿对应的实例注入，不校验类型。这些都是spring相关的 我觉得这个不应该是 `dubbo` 的 bug，如果你的 DemoServiceImpl 在 consumer项目中 且 手动指定了@service("testService")...
这个本身就是 对spring 使用的问题 是 ` @resource` 和 `@autowired` 的区别，可以看下 dubbo 2.x `@Reference` 注入spring容器 时的beanname， 你也可以 提下你的 issue 问题看一下
> 需要替换未 autowired 大多是因为不同类型 属性名称重复使用
我觉得这种注入的写法是不规范的，当然dubbo 是需要解决这种情况的。 @xiangzz159 @chenziqiang666 #10359