一个实际问题分析及解决之七：理解websphere的classloader

上一篇中提到了解决问题的两种选择，最后我们选择了第一种，因为我们时间有限而升级webspher的周期长。顺利地修改了第三方jar包并在本地测试通过。但部署到websphere服务器上还是出了问题，这次跟classloader有关了。

本地测试是普通的java项目，一个classloader，所以只需要注意jar的顺序即可。但我们的websphere上是multiple的classloader并且parent_first模式。

在实际解决问题的过程中，假如说我们要修改的是abc.jar中的类Z。为了减少改动和区别原三方jar包和自己的修改，我们把修改好后的类Z单独打成jar包：hacked.jar。

下一个问题是应该把hacked.jar放在哪里？为了确保在multiple class loader模式下能优先被加载，把hacked.jar放到了jvm的classpath里。但重启后报出了ClassNotFound的exception，而这个找不到的类明明就在abc.jar包中啊。再细细看了stacktrace发现里面涉及到了好几个class loader一层层调用，包括ext classloader, component class loader，隐约感觉问题跟class loader有关，进一步看发现加载不到的那个类正好是修改的类Z的父类。至此大致明白问题所在了，那个父类是application.ear目录下所以是由component
class loader加载的，而类Z是由ext class loader加载的，由于component class loader是继承自ext class loader，所以由component class loader加载的那个父类对ext class loader不可见，故报错了。

最后权衡了一下还是把类Z直接修改进abc.jar里并替换掉application.ear下的abc.jar，重启后则正常工作了。

至此，这个技术升级就完成了。中间经历了各种困惑与不解，因为不了解jdk的jsse机制。