Hessian/Burlap: 'com.github.pagehelper.Page' is an unknown class in TomcatEmbeddedWebappClassLoader

项目上线后，调用端系统会出现类似的报错

Hessian/Burlap: ‘com.github.pagehelper.Page’ is an unknown class in TomcatEmbeddedWebappClassLoader
context: ROOT
delegate: true
----------> Parent Classloader:
org.springframework.boot.loader.LaunchedURLClassLoader@38af3868
:
java.lang.ClassNotFoundException: com.github.pagehelper.Page

com.github.pagehelper.Page是PageHelper 工具中的一个类，但是在api层根本就没有使用，也就是说调用端系统应该是对这个类型无感知的，为什么在hessian反序列化时需要用到这个类呢？

因为PageHelper这个工具是国人开发的，所以估计在Google上也搜不到什么有价值的内容，而在百度上倒的确是找到了一些有反应同样情况的帖子，上面洋洋洒洒分析了一通，最后结论是需要在调用端系统引入这个包就好了，真的是让我吐血的回答。连追本溯源都做不到，就这样轻易落笔教学了。

找了一圈没找到什么有营养的答案后，决定还是自己寻找答案。如果在接口层使用了 com.github.pagehelper.Page这个类型，那么意味着接口层依赖了PageHelper的jar包，如果依赖了，那么调用端依赖服务提供端的时候必定也会自动依赖PageHelper，那么就不会出现上述报错了。所以只有一种可能，就是在接口层使用了com.github.pagehelper.Page的父类，在运行时实际返回的是com.github.pagehelper.Page类型，被hessian序列化传输到调用端后，反序列化时发现找不到对应类型而报错，那么看一下com.github.pagehelper.Page这个类的源码，猜想即得到验证——Page类继承了ArrayList

结论就是，在接口层返回的List或ArrayList对象实际上是一个Page类型。要解决问题很简单，重新创建一个List对象，将原来Page中的内容拷贝一份过去，返回手动创建的那个List对象即可。

如果像很多其他帖子一样，在调用端引入PageHelper 的确了应付了事，问题也能解决，但是我觉得作为一个程序员，要求自己写的代码更加优雅，有一点点代码洁癖，是一件更有追求的事情。用不到的东西就不该出现，就想PageHelper不该出现在调用端一样。