javax.transaction.* 类的 WebSphere 9 上的 LinkageError答案

【问题标题】：LinkageError on WebSphere 9 for javax.transaction.* classesjavax.transaction.* 类的 WebSphere 9 上的 LinkageError
【发布时间】：2020-03-24 00:40:04
【问题描述】：

我有一个曾经在许多 Web 服务器（tomcat、jboss、weblogic 和 websphere）上运行良好的 Web 应用程序。但是，现在在 WebSphere 9 上部署时出现错误。

该应用程序包含 jar javax.transaction-api-1.2。它的一些类，例如javax.transaction.xa.XAResource，也包含在 Java SE 中，但不是全部。有些是 Java EE 特有的，并且是我的应用程序中的一些 3rd-party 库所必需的。该应用程序始终使用子优先（父最后）类加载器进行部署。当应用程序尝试加载 Oracle JDBC 驱动程序时，WebSphere 9 在启动期间抛出此错误：

java.lang.LinkageError: loading constraint violation: loader "com/ibm/ws/classloader/CompoundClassLoader@7157be44" previously initiated loading for a different type with name 
"javax/transaction/xa/XAResource" defined by loader "com/ibm/oti/vm/BootstrapClassLoader@422c7b1b"

请注意，我们实际上并没有在应用程序中使用 XA 事务，而是使用常规事务。

在其他服务器和以前版本的 WebSphere 上，这从来都不是问题。服务器并不关心我们从战争内部加载XAResource，即使它之前加载在服务器的某个地方。现在 WebSphere 9 不同了，它说应用程序类加载器已经从服务器加载了这个类，但我不知道为什么或何时发生这种情况。

知道如何解决这个问题吗？

【问题讨论】：

标签： websphere linkageerror

【解决方案1】：

从您的应用程序中删除事务 API。 JTA 1.2 已经包含在服务器中，并且在您的应用程序中没有任何价值。除非您 100% 确定它们在技术上是必要的，否则将 Java EE/SE API 引入最后一个父类加载器总是有风险的，因为它们可能会导致类似这样的问题。

我不能说这在以前的服务器版本中是如何工作的（在执行此类链接问题方面已经发生了一些 Java 级别的更改），但解决方案相当简单。

【讨论】：

我需要该 jar 用于其他未提供 jta 的服务器。我试图避免为不同的服务器提供不同的战争档案
是否有技术原因要求您使用 parent-last 类加载器策略运行？仅当您的应用程序中有特定内容时，您才需要使用您的版本而不是服务器的版本。 LinkageErrors 的风险比 parent-last 高几个数量级，因为它使一个类更有可能由多个类加载器定义。
当然有一个技术原因 - 父类优先类加载器使我们的应用程序容易受到服务器环境变化和其库中的错误的影响。在过去的 15 年中，我们一直在这个应用程序中使用 parent-last，尽管在 j2ee 的演变和许多不同的服务器中。使用 parent-last 给了我们隔离和稳定性，直到现在它一直有效。它也适用于 jboss 和 weblogic，以及以前版本的 websphere（以及没有 jta 的 tomcat）

【解决方案2】：

最后我们做了两件事来解决这个问题。

1) 我们将 jta jar 升级到 1.3 版（链接here）。这个 jar 通过避免重复类解决了这个问题——它只包含 J2EE 类并省略了已经包含在 JVM 中的 J2SE 类。 2) 我们将 WebSphere 服务器从 9.0.0.7 升级到 9.0.0.11。

当时，我怀疑只升级 jar 就足够了，但我们的 QA 遇到了一些问题，他们还升级了服务器。由于时间不够，我们没有进一步调查，就决定两者都做。

【讨论】：