0

I'd like to avoid getting

javax.enterprise.system.tools.deployment.common: Exception while visiting module-info.class

exceptions like the one below in my log file during Glassfish4 startup and deployment.

We're using glassfish4 under Java8 and upgrading these is not an option at the moment. We do however need relatively new versions of Jackson (2.10.3) to support scribejava and java-jwt.

The exceptions occur during startup and deploy because the "fat" .war file contains e.g. WEB-INF/lib/jackson-annotations-2.10.3.jar and this relatively new jackson-annotations-2.10.3.jar file contains a module-info.class at its root compiled for java 9 (version 53). Which causes glassfish4 running on Java8 to log an exception like below. The exceptions are logged with severity ERROR, but I have not (yet?) found anything that doesn't work because of this.

What can I do to remove the exceptions from the log?

What does work, but is nasty and error prone is: Extract the .war file into a folder. For each jackson jar file zip -d $file module-info.class. Repackage the .war file with the modified jackson jar files. Now I've surgically removed the module-info.class files and it works without exceptions, but it has a nasty smell.

What I'm hoping for is one of:

  • An option to glassfish4 to just ignore Java9 or newer files in .jar files that it can't read
  • A way to block glassfish4 loading of certain class files, e.g. module-info.class from WEB-INF/lib/jackson-annotations-2.10.3.jar
  • A way for gradle to exclude the above from the war file, so glassfish4 never sees them

I haven't even been able to find any documentation on javax.enterprise.system.tools.deployment.common. Glassfish4 is supposed to use Java EE 7 but the docs don't mention that class.

An example exception:

20:45:00.766 ERROR [  ](157) javax.enterprise.system.tools.deployment.common: Exception while visiting module-info.class of size 190
    java.lang.IllegalArgumentException: null
        at org.glassfish.hk2.external.org.objectweb.asm.ClassReader.<init>(ClassReader.java:170) ~[asm-all-repackaged.jar:?]
        at org.glassfish.hk2.external.org.objectweb.asm.ClassReader.<init>(ClassReader.java:153) ~[asm-all-repackaged.jar:?]
        at org.glassfish.hk2.external.org.objectweb.asm.ClassReader.<init>(ClassReader.java:424) ~[asm-all-repackaged.jar:?]
        at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:359) [class-model.jar:?]
        at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:165) [kernel.jar:?]
        at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:127) [kernel.jar:?]
        at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:345) [class-model.jar:?]
        at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:68) [class-model.jar:?]
        at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:304) [class-model.jar:?]
        at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:293) [class-model.jar:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_265]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_265]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_265]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]

I had similar exceptions when I included log4j versions > 2.9 because it is now a "multi-release jar" (see changelog) and has **/version/9/*.jar files, but removing log4j as a dependency removed those.

I can't get rid of new Jackson libs as dependencies though.

Peter V. Mørch
  • 13,830
  • 8
  • 69
  • 103
  • I could of course just [filter out the exception](https://stackoverflow.com/questions/26166281/how-to-filter-a-specific-exception-from-log4j) from being logged. That has a nasty smell too... – Peter V. Mørch Sep 13 '20 at 23:07
  • A multi-release .jar file shouldn’t be a problem. The whole point of a multi-release file is that the 9+ class files are under META-INF, and won’t be seen by classloaders of pre-9 versions of Java. – VGR Sep 14 '20 at 14:32
  • @VGR: "shouldn't"... :-) It does in fact cause exceptions like the one above, though. Also, the `module-info.class` is directly in the root of the jar, not under `META-INF`. – Peter V. Mørch Sep 15 '20 at 01:59
  • Correct, shouldn’t. I have a hard time believing a Java 8 classloader is going to pay attention to any class files under META-INF. However, module-info.class also needs to be under META-INF/version/9. If a Jackson .jar put its Java 9+ classes under META-INF/version and not its module descriptor, then Jackson screwed up. – VGR Sep 15 '20 at 02:57
  • Perhaps. But when I had log4j as a dependency, Glassfish4 also complained about its files, even though they were under `META-INF/version/9`. So glassfish4 is also doing something "wrong". I'm beginning to think this is because glassfish4 was released in 2013 and Java9 in 2017. What glassfish4 does made sense back then, but not now... – Peter V. Mørch Sep 15 '20 at 07:58
  • I looked at a Jackson .jar and it does indeed have a module-info.class in its root, compiled with Java 9, even though all of its other class files are compiled with Java 6. As far as I’m concerned, this is a broken .jar file which might or might not work with various classloaders. It certainly isn’t a proper multi-release jar. And as far as I’m concerned, you are fully justified in altering the file as necessary. – VGR Sep 16 '20 at 14:43

0 Answers0