Error making application deploy in GlassFish: org.objectweb.asm.ClassReader.init - java.lang.ArrayIndexOutOfBoundsException

Question

Error making application deploy in GlassFish: org.objectweb.asm.ClassReader.init - java.lang.ArrayIndexOutOfBoundsException

Navigation

#1 by (2 votes)

4

Questions

Why does GlassFish 3.1.2.2 run ASM, and does this ASM fail to load my dependency classes?
How do I get my application uploaded?
Why does not it happen on other servers than with GlassFish 3.1.2?

Context

I'm using GlasshFish 3.1.2.2 (build 5) as an application container on the X server, I'm not able to upload my application there. On the Y server with GlassFish 3.1.2 (build 23)

Recently, we uploaded Hikari's Connection Pool as a dependency ( link to Maven artifact ). This involved moving Java from the container to Java 8.

On a client that uses our Web application on the server side of them ( aka server X ), I was unable to upload the application. Until the previous version, the version before HikariCP, was rising quietly on the X server.

The error you are giving 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 creating one of our objects, which internally uses 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

glassfish

asked by anonymous 08.11.2017 / 14:15

1 answer

Open html page in the modal DOUBT Overuse of SELECT and Standard Tables

score 2 · Answer 1

This involved moving Java from the container to Java 8.

Probably because somewhere the system uses Java 8 functionality, such as lambdas.

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

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

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

Because HK2 does dependency injection, and it sucks too much, to the point of using ASM. ASM fails due to outdated version as explained above.

How do I get my application uploaded?

Update ASM, and continue deploy as usual.

Why does not 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 reach a definitive conclusion in this case, the difference between them is minimal. For the Class Model For Hk2 component, one uses the 1.1.14 and the other at 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 keep several versions of the same package. So it's not always easy 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 in your case, someone manually upgraded the ASM package on this server.

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