朝夕不待人的博客

背景因为项目接口需要进行解密,需要对数据进行统一处理,就使用了ReuqestBodyAdvice进行数据解密处理,但是偶然的发现supports方法会出现执行两次的情况,觉得有点奇异就进行了一次断点调试,然后就发现了执行两次的原因;过程1.默认supports方法返回false,表示不做任何处理:2.默认supports方法返回true,表示对数据进行处理:如图所示无论supports方法返回true还是false,只要这个ReuqestAdvice存在并且在spring中生效,suppor

起因发现这个问题的起因是前端联调接口的时候发现统一的异常处理没有发挥作用,我们定义的处理的异常类型为AppException(国际惯例继承于RuntimeException),但是Dubbo服务端实际返回的异常变成了RuntimeException,我们自定义的异常处理没有发生作用.深入研究Dubbo的异常处理针对发现的问题,查阅了相关的代码和源码发现Dubbo有一个自带的过滤器接口声明了,并且实现了一个异常过滤器,当服务端抛出异常给消费端时异常都会被该异常过滤器处理(其实可以转换思维理解一下,rpc

前言调用一个第三方SDK的时候使用该SDK提供的Bean类封装数据调用,在使用BeanUtils.copyProperties的时候发现有些数据没成功的copy过去,使用DeBug进行源码分析,发现有的属性可以顺利获取到write方法.然后发现所有属性的read方法都是顺利获取到的分析思考了一下觉得可能跟write方法有关系,就点开Bean查看了一下,发现无法获取到write方法,结果发现方法在set值的同时也返回实例本身用做链式调用.方法如下:,看到这个方法的时候我当场就是:.然后自己写了一个