Websphere 讨厌多版本的 jars

Question

此问题与 Jetty 中的类似问题重复，但我找不到有关 Websphere 的文献

• https://github.com/eclipse/jetty.project/issues/1797
• Error scanning entry "module-info.class" when starting Jetty server

我有一个运行在 Java 7 上的 Websphere 8.5.5.7。直到今天我们才发现将 log4j 从 2.7 升级到 2.10 会破坏启动。以下是众多堆栈跟踪之一：

[01/03/18 10.12.14:154 CET] 000003d9 ecs           W com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl scanJAR unable to open input stream for resource module-info.class in archive WEB-INF/lib/log4j-api-2.10.0.jar
                                 java.lang.IllegalArgumentException
    at org.objectweb.asm.ClassReader.<init>(Unknown Source)
    at org.objectweb.asm.ClassReader.<init>(Unknown Source)
    at org.objectweb.asm.ClassReader.<init>(Unknown Source)
    at com.ibm.ws.ecs.internal.scan.impl.ClassScanner.scanInputStream(ClassScanner.java:147)
    at com.ibm.ws.ecs.internal.scan.impl.ClassScanner.scanInputStream(ClassScanner.java:124)
    at com.ibm.ws.ecs.internal.scan.impl.ClassScanner.scanInputStream(ClassScanner.java:120)
    at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.scanJAR(ScannerContextImpl.java:275)
    at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.scanJARs(ScannerContextImpl.java:315)
    at com.ibm.ws.ecs.internal.scan.context.impl.WARScannerContext.scanInternal(WARScannerContext.java:76)
    at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.scan(ScannerContextImpl.java:87)
    at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.getScannedClasses(ScannerContextImpl.java:70)
    at com.ibm.ws.webcontainer.webapp.WebAppImpl.scanForHandlesTypesClasses(WebAppImpl.java:760)
    at com.ibm.ws.webcontainer.webapp.WebAppImpl.initializeServletContainerInitializers(WebAppImpl.java:601)
    at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:406)

基本上，log4j 开发人员有一个伟大的（但不幸的）想法，即使用 Java 9 的多版本 jar 来适应较旧的 Java 运行时。

我们的安装无法升级。这些是版本，我们必须保留它们。我试图用谷歌搜索带有 websphere 的多版本 jar，但似乎没有文献。

我想问是否有任何配置解决方法至少在目标 websphere 版本中的选定包中禁用对 jar 的大规模扫描。

Answer 1

为此有一个现有的 APAR。请参阅 APAR PI89708。

如果这不能解决问题，您应该打开一个 PMR 以便 IBM 可以解决它。

传统的 WebSphere Application Server 确实提供了一种机制来减少对 JAR 文件的扫描量。但是，这可能（或可能不是）是解决此问题的方法，因为并非 WAS 的所有组件都尊重注释扫描过滤器。虽然它仍然值得一看，因为减少扫描活动可以缩短部署时间。

查看 WAS_HOME/properties 下的 amm.filter.properties 文件。 将不想扫描的 JAR 文件的名称添加到“Ignore-Scanning-Archives”属性。有更多选项可用于指定要从扫描中过滤的 JAR。您可以找到更多信息here。

另请注意，WAS 8.5.5 是在多版本 JAR 存在之前发布的。因此，必须在服务中添加支持，或更准确地说是容差。我说宽容，因为目前不支持 Java 9。目前，WAS 只需要容忍 META-INF 目录下类的存在。

如果您绝对无法升级或修补应用程序服务器，那么最简单的选择是修改 log4J JAR 文件，删除 META-INF 目录下的类。我知道这也是不可取的，因为您不必修改第三方 JAR，但我怀疑过滤器在这种情况下是否可以正常工作。所以，如果不给应用服务器打补丁，它可能是唯一的选择。

正如您在评论中指出的那样，在这种特殊情况下，由于 LOG4J 没有 JAVA EE 注释，因此可以忽略警告消息。应用程序应该正常启动和运行。但是，如果 JAR 包含 Java EE 注释，那么这些注释将不会被处理。如果是这种情况，我希望应用程序能够启动，但它可能无法正常运行。

> 自此问题的原始答案以来，添加了额外的 APAR。以下是 APAR 的完整列表： PI89708、PI93744、PI96826、PH02014、PH03710。