我写这篇文章是作为提示和警告,而不是绝对的解决方案。 我将尝试针对我的案例(WebSphere 8.5.5)返回一种解决方法,但是我确信其他开发人员和应用程序也会受到影响。 我已经花了一些时间来找出问题的原因,所以暂时,这篇文章将有助于增加上述关键字的搜索索引,并链接到休眠问题跟踪器。
在当前正在进行的项目中,由于Hibernate ORM 4.2.0版库中的错误,我决定在安装程序中将库版本向前移动并升级到最新版本。 Hibernate当前以版本4.2.8作为最新的JPA 2.0兼容版本,而4.3.0是第一个正式的JPA 2.1兼容。 由于我正在开发Jee6版本,因此我选择升级到4.2.8。
最终在4.2.8及更高版本中,库中实现了“ 严重的 ”内部API更改。 Hibernate迁移到javaassist的新版本,该版本引入了一些新的内部API调用和接口。 请参阅此处的链接问题。 因此,版本4.2.8将作为javassist- 3.18.1-GA的依赖项获取到您的应用程序。
最终,如果您碰巧引入了
- 对Javassist版本的多个依赖
- 一个容器通过“父级”类加载器为您的耳朵/战争提供了较旧的版本
然后,您将遇到类似这样的问题。 简而言之,如果您的容器中的活动类加载器偶然捕获了旧版本的javassist,则在加载jpa实体或执行相关代码时,您很可能会遇到奇怪的类强制转换异常或“未找到类”异常指向到过时的javassist API。
恕我直言,此更改应该已经引入到Hibernate的“主要”版本中,但是我很明白,有时开发人员的需求不能由全球开发人员用户社区的不同需求和设置来强制要求。 因此,这只是我对“应该存在”的看法,我仍然认为Hibernate是最好的Java ORM。
如果您遇到这种情况,请先采取以下措施:
- 检查您的可部署jar依赖项,并找到Javassist的任何其他实例,尤其是较旧的版本-根据您的容器和类加载设置检查如何加载它们。
- 如果您没有明确包括任何额外的依赖项,并且唯一的实例是“从休眠中获取”的实例(如我的案例),那么您需要检查是否从应用程序或服务器级共享库中加载了较旧版本的javassist或从应用程序服务器中的“共享”类加载器。 (我仍在为Websphere 8.5.5进行这一工作)。 您可以尝试共享库的加载顺序或类加载模式(父项优先/父项末次)
- 如果您找不到基于以上两点的解决方案,或者您尝试在应用程序上尝试使用类加载策略,并且证明确实很麻烦,那么只需切换到版本4.2.7 ,这似乎是最后一个解决方案。向后兼容旧版本的Javassist。
如果您是JBoss EAP 6.2和JBoss Wildfly 8用户,那么您会很安全,这意味着这些容器已经带有“最新” javassist版本,但是您仍然需要对应用程序可能引入的任何潜在冲突版本进行分类。
希望我会为我的情况提供解决方法。