Websphere hates multi-release jars

Question

This problem is duplicate to similar problems in Jetty, but I could not find literature about Websphere

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

I have a Websphere 8.5.5.7 running over Java 7. Only today we discovered that upgrading log4j from 2.7 to 2.10 breaks the startup. Following is one of the many stack traces:

[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)

Basically the log4j developers had the great (but unlucky) idea of using multi-release jars for Java 9 to accommodate older Java runtimes.

Our installation cannot be upgraded. Those are the versions and we must keep them. I have tried to google around for multirelease jars with websphere but there seems to be no literature.

I would like to ask if there is any configuration workaround to disable massive scanning of jars at least in selected packages in the targeted version of websphere.

Answer 1

There is an existing APAR for this. See APAR PI89708.

If that does not fix the problem, you should open a PMR so that IBM can fix it.

WebSphere Application Server traditional does provide a mechanism to reduce the amount of scanning of JAR files. However, that might (or might not) be a workaround for this problem, since not all components of WAS respect the annotation scanning filters. Though it is still worth looking at since reducing the scanning activity can improve deployment time.

Take a look at the amm.filter.properties file under WAS_HOME/properties. Add names of JAR files that you do not want scanned to the "Ignore-Scanning-Archives" property. There are more options for specifying JARs to be filtered from scanning. You can find more information here.

Also note that WAS 8.5.5 was released before multi-release JARs existed. So the support, or more accurately tolerance, has to be added in service. I say tolerance, because Java 9 is not supported at this time. For now, WAS simply has to tolerate the existence of classes under the META-INF directory.

If you absolutely cannot upgrade or patch the application server, then the simplest option is to modify the log4J JAR file, removing the classes under the META-INF directory. I know that is not desirable either, since you shouldn't have to modify a third-party JAR, but I have doubts that the filter will work in this case. So, without patching the application server, it might be the only option.

As you pointed out in your comment, in this particular case, since LOG4J does not have JAVA EE annotations, the warning message can be ignored. The application should start and function normally. If however, the JAR contained Java EE annotations, then those annotations would not have been processed. If that were the case, I would expect the application to start, but it might not function correctly.

> Additional APARs were added since the original answer to this question. Here is the complete list of APARs: PI89708, PI93744, PI96826, PH02014, PH03710.