Error deploying application in Glassfish: org.objectweb.asm.ClassReader. <init> -> java.lang.Arrayindexoutofboundsexception

Question

Questions

• Why Glassfish 3.1.2.2 runs ASM and this ASM fails to load the classes of my dependency?
• How do I get my application up?
• Why doesn’t it happen on other servers than with Glassfish 3.1.2?

Context

I’m using Glasshfish 3.1.2.2 (build 5) as the application container on the X, I’m not getting my application up there. Already on the server Y with Glassfish 3.1.2 (build 23)

Recently, we have inserted as dependency the Connection Pool hikari (link to Maven artifact). This meant moving Java from container to Java 8.

On a client that uses our web application on their server side (aka server X), I couldn’t get the application up. Until the previous version, the version before Hikaricp, was going up peacefully on the server X.

The mistake you’re making is:

Exception while visiting com/zaxxer/hikari/metrics/micrometer/MicrometerMetricsTracker.class of size 6582
java.lang.ArrayIndexOutOfBoundsException: 27392  
    at org.objectweb.asm.ClassReader.readClass(Unknown Source)  
    at org.objectweb.asm.ClassReader.accept(Unknown Source)  
    at org.objectweb.asm.ClassReader.accept(Unknown Source)  
    at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)  
    at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)  
    at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)  
    at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)  
    at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)  
    at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)  
    at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)  
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)  
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)  
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)  
    at java.lang.Thread.run(Thread.java:748)  

It also occurs with other Hikaricp classes:

• com/zaxxer/hikari/metrics/micrometer/MicrometerMetricsTracker.class
• com/zaxxer/hikari/metrics/prometheus/HikariCPCollector.class
• com/zaxxer/hikari/pool/HikariPool.class
• com/zaxxer/hikari/pool/ProxyConnection$ClosedConnection.class
• com/zaxxer/hikari/util/ConcurrentBag.class
• com/zaxxer/hikari/util/PropertyElf.class

This ends up generating an error in the creation of one of our objects, which uses internally Hikari classes and inherits from com.zaxxer.hikari.HikariDataSource:

<Exception encountered during context initialization - cancelling refresh attempt>
org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [br.com.softsite.ssm.security.dataSource.SSHikariDataSource] for bean with name 'dataSource' defined in ServletContext resource [/WEB-INF/spring-jdbc-homologacao.xml]; nested exception is java.lang.ClassNotFoundException: br.com.softsite.ssm.security.dataSource.SSHikariDataSource
    at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1278)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBeanFactory.java:575)
    at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:1347)
    at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:913)
    ... 71 more
Caused by: java.lang.ClassNotFoundException: br.com.softsite.ssm.security.dataSource.SSHikariDataSource
    at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1509)
    at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359)
    at org.springframework.util.ClassUtils.forName(ClassUtils.java:265)
    at org.springframework.beans.factory.support.AbstractBeanDefinition.resolveBeanClass(AbstractBeanDefinition.java:419)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doResolveBeanClass(AbstractBeanFactory.java:1299)
    at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1270)
    ... 74 more

The classes used are:

• com.zaxxer.hikari.HikariConfig
• com.zaxxer.hikari.HikariDataSource

Answer 1

This meant moving Java from container to Java 8.

Probably because somewhere, the system uses Java 8 features such as Windows.

I would say, that the version of the ASM being used should be the 3.3. While support for Java 8 has only been introduced in the version 5.0.

I suggest updating the ASM dependency to version 5.2 or 6.0.

Why Glassfish 3.1.2.2 runs ASM and this ASM fails to load classes of my dependency?

Because HK2 injects addiction, and he’s very nosy, to the point of using ASM. ASM crashes due to outdated version as explained earlier.

How do I get my application up?

Upgrade ASM, and continue deploying as you have always done.

Why doesn’t it happen on other servers than with Glassfish 3.1.2?

If I understand correctly, Glassfish 3.1.2 works, but Glassfish 3.1.2.2 does not. It is difficult to come to a definitive conclusion in this case, the difference between them is minimal. For the Class Model For Hk2 component, one uses the version 1.1.14 and the other to 1.1.15. The cause may even be a line in the source code.

In Glassfish you can run the application in Osgi environment, which allows you to maintain several versions of the same package. So it’s not always simple to tell which version you’re actually using. This means that the factory version may be 3.3, but you are using another version. I believe that in your case, someone manually updated the ASM package on this server.

The last remaining theory is that that server works correctly because it does not load Hikari, so ASM does not have the opportunity to generate the error.