Albumen Kevin
Albumen Kevin
> > > 想测试`ConfigValidationUtils#checkQosDependency()`方法（虽然是私有方法），该方法没有返回值、没有抛异常之类的可测试项，只有logger打印日志。于是就考虑注入Mock(logger)，但是logger是final字段，只好利用反射来处理下，但是JDK17好像为提高安全性不支持这种操作。一时间没想到好办法。 > > > 考虑放弃测试该方法内部，只测试该方法是否能被 `#validateApplicationConfig()`正确调用。能否提供一些其他解决思路？谢谢。 > > > > > > junit 可以配置验证的版本，配置 range 到 jdk 14 就行 > > 逐版验证了，从jdk 12开始就不行。 是不是 mockstatic 版本太低了
> > > > > 想测试`ConfigValidationUtils#checkQosDependency()`方法（虽然是私有方法），该方法没有返回值、没有抛异常之类的可测试项，只有logger打印日志。于是就考虑注入Mock(logger)，但是logger是final字段，只好利用反射来处理下，但是JDK17好像为提高安全性不支持这种操作。一时间没想到好办法。 > > > > > 考虑放弃测试该方法内部，只测试该方法是否能被 `#validateApplicationConfig()`正确调用。能否提供一些其他解决思路？谢谢。 > > > > > > > > > > > > junit 可以配置验证的版本，配置 range 到 jdk...
retry 是一个客户端行为，不会受服务端的配置所影响。 背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的 timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
现在高版本 serialization 会在请求的时候先配置好，不会落到通过 channel 获取的，channel 只是一个兜底策略
`org.apache.dubbo.rpc.protocol.dubbo.DubboCodecSupport#getRequestSerialization` `org.apache.dubbo.rpc.protocol.dubbo.DubboCodecSupport#getResponseSerialization`
> 好的，感谢。 哪也就是说 2.7.8 以下的版本都会有这个问题？ 是的
close for duplicated with #10748
是个好的想法，可以看下怎么完善下