Websphere讨厌多版本jars
这个问题与Jetty中的类似问题相同，但是我找不到关于Websphere的文献
- https://github.com/eclipse/jetty.project/issues/1797
- Error scanning entry "module-info.class" when starting Jetty server
以下是众多堆栈跟踪中的一个：
[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开发人员有一个伟大的(但不幸的)想法，即使用Java9的多版本jars来适应较旧的Java运行时。
我们的installation 不能升级为。这些就是版本，我们必须保留它们。我试着在谷歌上搜索websphere的多版本jars，但似乎没有任何文献。
我想问是否有任何配置解决方法来禁用jars的大规模扫描，至少在目标版本的的选定包中是这样。
回答 1
Stack Overflow用户
发布于 2018-03-03 05:59:36
对此有一个现有的APAR。参见APAR PI89708。
如果这还不能解决问题，那么您应该打开一个PMR，以便IBM可以修复它。
传统的WebSphere应用服务器确实提供了一种机制来减少JAR文件的扫描量。但是，这可能是(也可能不是)解决此问题的方法，因为并非所有的WAS组件都遵守注释扫描过滤器。尽管它仍然值得一看，因为减少扫描活动可以缩短部署时间。
查看WAS_HOME/ amm.filter.properties下的属性文件。将不希望扫描的JAR文件的名称添加到"Ignore-Scanning-Archives“属性中。有更多选项可用于指定要从扫描中过滤的JAR。你可以在here上找到更多信息。
还要注意的是，WAS 8.5.5是在多版本JAR出现之前发布的。因此，必须在服务中添加支持，或者更准确地说，是容差。我之所以说容忍，是因为目前还不支持Java 9。现在，WAS只能容忍META-INF目录下类的存在。
如果您绝对不能升级或修补应用服务器，那么最简单的选择是修改META-INF文件，删除log4J -INF目录下的类。我知道这也是不可取的，因为您不应该修改第三方JAR，但我怀疑过滤器在这种情况下是否可以工作。因此，如果不为应用服务器打补丁，这可能是唯一的选择。
正如您在注释中指出的，在这种特殊情况下，由于LOG4J没有JAVA注释，因此可以忽略警告消息。应用程序应正常启动和运行。但是，如果JAR包含Java EE批注，那么这些批注就不会被处理。如果是这种情况，我希望应用程序能够启动，但它可能无法正常工作。
Additional APARs were added since the original answer to this question. Here is the complete list of APARs: [PI89708](http://www-01.ibm.com/support/docview.wss?uid=swg1PI89708), [PI93744](http://www-01.ibm.com/support/docview.wss?uid=swg1PI93744), [PI96826](https://www-01.ibm.com/support/docview.wss?uid=swg1PI96826), [PH02014](https://www-01.ibm.com/support/docview.wss?uid=swg1PH02014), [PH03710](http://www-01.ibm.com/support/docview.wss?uid=swg1PH03710).
https://stackoverflow.com/questions/49067032
复制相似问题