java.lang.ArrayIndexOutOfBoundsException: 41981 during tomcat start - java

I am getting this exception during tomcat start. I am using jdk1.8.0_152, apache-tomcat-8.5.24
I have been updating my elasticsearch from version 1.7 to 6.0. For that I had to include few new jars and had to update few existing to latest versions.(commons-io-2.6,lucene-core-7.0.1,log4j-api-2.9.1) After that I am getting this error on tomcat starting.
SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log
StandardWrapper.Throwable java.lang.ArrayIndexOutOfBoundsException:
41981 at org.objectweb.asm.ClassReader.(Unknown Source) at
org.objectweb.asm.ClassReader.(Unknown Source) at
org.objectweb.asm.ClassReader.(Unknown Source)

What version of asm do you use? According to this post https://github.com/joaoarthurbm/designwizard/issues/36:
asm-3.1 doesn't support lambdas expression available in JDK 8.
So you might be want to upgrade to asm 5.0.1 or higher.

Related

Exception when deploying on glassfish: ArrayIndexOutOfBoundsException: 9578

when I deploy my war file on tomcat it is ok but when I deploy it on glassfish it gives the exception, I searched but found no result how to solve this.
java.lang.ArrayIndexOutOfBoundsException: 9578
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$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
...............
[#|2018-10-07T15:19:22.345+0330|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=84;_ThreadName=Thread-2;|Exception while loading the app|#]
[#|2018-10-07T15:19:25.182+0330|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=84;_ThreadName=Thread-2;|Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'TestController' defined in file [E:\glassfish3-Reservation\glassfish3\glassfish\domains\domain1\applications\myproject\WEB-INF\classes\com\company\controller\TestController.class]: Instantiation of bean failed; nested exception is java.lang.ExceptionInInitializerError
Your best option is to update your Glassfish server if you can. Your version 3.1.2 is way too old, the current one is 5.0.
Another option would be to look for Lambda expressions in the TestController class and to remove or replace them with standard code.
This exception seems to occur when you are using Lambda expressions or newer Java bytecode with a version of asm.jar which is too old. This is related to your old version of Glassfish which comes bundled with Jersey 1.x which has bundled asm.jar 3.1. This version seems to be not fully compatible with Java8 or newer bytecode.
More related information:
Strange java.lang.ArrayIndexOutOfBoundsException thrown on jetty startup
Java 8 Lambda Expression Within REST Service not working
ArrayIndexOutOfBoundsException when using Java 8 language features

Why Java doesn't recognize net.sf.jasperreports.engine.util.JRLoader class?

Good afternoon.
I am working on JDK 1.6.
I am trying to integrate JasperReports to the Java Web Application of company where I work. First, I created an simple Java Application for to test the reports generation, and I used the next libraries (jars):
Commons collections 3.2.1
Commons beanutils 1.9.0
Commons digester 2.1
Commons logging 1.2
Groovy all 1.8.0
Joda time 2.0
JasperReports 6.0.0
With these I was able to create a report but, when I transfered this libraries to the Java Web Application,happened the next exception:
javax.faces.FacesException: #{bean.functionCalled}: java.lang.reflect.InvocationTargetException
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
at org.primefaces.application.CleanupActionListener.processAction(CleanupActionListener.java:42)
...
Caused by: javax.faces.el.EvaluationException: java.lang.reflect.InvocationTargetException
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
... 51 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
... 52 more
Caused by: java.lang.NoClassDefFoundError: net/sf/jasperreports/engine/util/JRLoader
... 85 more
Caused by: java.lang.ClassNotFoundException: net.sf.jasperreports.engine.util.JRLoader
at java.net.URLClassLoader$1.run(Unknown Source)
...
... 86 more
I found out that the cause of the problem is the commons loggin version, or the libraries combination.
By default, this Java Web Application has the next libraries:
Commons collections 3.2
Commons beanutils 1.6
Commons digester 1.8.1
Commons logging 1.1.1
Groovy all 1.5.4
Joda time 1.6
I'm making differents versions combinations but not working, the problem persist.
What you recommend me?
Thank you so much.
This is a missing jars in the class path issue.
I had this issue and found that with by adding the missing jars to the class path it resolved the issue.
From the below article java.dzone.com article here I found that the minimal jars necessary are...Now The versions numbers have changed but with these libraries only I managed to get it working.
jasperreports-3.5.3.jar and above version
commons-digester-2.1.jar
commons-collections-3.2.jar (commons-collections.jar)
commons-logging-1.2.jar
commons-beanutils.jar
iText-5.0.jar (used infor PDF exporting)

Jersey 1.x - compatibility

Is Jersey 1.8 compatible with Java 8?
Also, is Jersey 1.8 compatible with WildFly 8 on Java 8?
I developed and I am now maintaining a REST
web service project which produces a WAR.
We started having some problems with this like 6 months ago
(but btw we only now noticed them). See error and screenshot below.
After doing quite some research on the web,
it seems to me the problems are related to the fact that our project
was migrated to Java 8 and WildFly 8 (previously it was running on Tomcat
6 with Java 6).
So... I thought the solution is to migrate to at least Jersey 1.9
(we don't want to use the Jersey 2.x line).
I tried it but I am getting the same error.
So... is Jersey 1.x at all compatible with WildFly 8 and Java 8?
The error which we started getting looks like this.
07:27:33,894 INFO [com.sun.jersey.api.core.WebAppResourceConfig] (default task-7) Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes
07:27:36,984 ERROR [io.undertow.request] (default task-7) UT005023: Exception handling request to /rpt/rpt-rest-service/report: java.lang.ArrayIndexOutOfBoundsException: 1901
at org.objectweb.asm.ClassReader.readClass(Unknown Source) [asm-3.1.jar:3.1]
at org.objectweb.asm.ClassReader.accept(Unknown Source) [asm-3.1.jar:3.1]
at org.objectweb.asm.ClassReader.accept(Unknown Source) [asm-3.1.jar:3.1]
at com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:133) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.core.spi.scanning.JarFileScanner.scan(JarFileScanner.java:97) [jersey-core-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.scanning.WebAppResourcesScanner$1.f(WebAppResourcesScanner.java:94) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.core.util.Closing.f(Closing.java:71) [jersey-core-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.scanning.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:92) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.scanning.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:79) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.WebAppResourceConfig.init(WebAppResourceConfig.java:100) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.WebAppResourceConfig.<init>(WebAppResourceConfig.java:87) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.WebAppResourceConfig.<init>(WebAppResourceConfig.java:72) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.WebComponent.getWebAppResourceConfig(WebComponent.java:672) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:414) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:581) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.WebServletConfig.getDefaultResourceConfig(WebServletConfig.java:87) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:703) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
.......
The same exception I get in the browser when calling my REST web service.
Note that there have been no code or library or config changes in this project
(which produces that WAR). I believe only the deployment environment was changed.
As it usually happens an hour or two after asking here, I found the solution.
The solution is to upgrade Jersey from 1.8 to some later version from the 1.x Jersey line.
First I tried a minimalistic approach and upgraded to version 1.9 but that one had the same issue.
So then I just upgraded to the latest version from the 1.x Jersey line (which is version 1.19.3 as of this moment). This solved the problem.

Is there any dependency between Spring and Apache Tomcat Jar

Following is the timeline of how i got error in my application
Used Spring 2.5.3 and tomcat 7.0.27 - No Error
Upgraded to Spring 3.1.1 with same tomcat (7.0.27) - No Error
Upgraded tomcat to 7.0.42, used with Spring 3.1.1 - VerifyError
When i stop my application, i get 1000 verifyerrors (seperate error for every destroyBean) when i upgraded to tomcat 7.0.42.
Following is the Stack Trace:
java.lang.VerifyError: (class: org/springframework/orm/jpa/EntityManagerFactoryUtils, method: convertJpaAccessExceptionIfPossible signature: (Ljava/lang/RuntimeException;)Lorg/springframework/dao/DataAccessException;) Wrong return type in function
at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessBeforeDestruction(PersistenceAnnotationBeanPostProcessor.java:357)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:193)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:498)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:509)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:442)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1066)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1040)
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:988)
at org.springframework.web.context.ContextLoader.closeWebApplicationContext(ContextLoader.java:556)
at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:142)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4980)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5626)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Possible Cause:
fixed EntityManagerFactoryUtils's "convertJpaAccessException" to always return rather than throw DataAccessExceptions
This line is in ChangeLog of Spring 2.5.6
But my application works fine with Spring 3.1.1 and tomcat 7.0.27 but throws this error when upgraded to tomcat 7.0.42
AFAIK, Tomcat doesn't depend on Spring, and Spring doesn't depend on Tomcat. Not in any version of either.
I suspect that in the intermediate version of your application after "upgrade to Spring 3.1.1 with same tomcat (7.0.27)", you either didn't trigger that code to be run. Note that it is happening in code that is run when a webapp is shut. If you never attempted a clean shutdown in the intermediate version of your application, that postProcessBeanBeforeDestruction method wouldn't be called on that bean, and the problem wouldn't arise.
My guess is that the real problem is caused by mixing versions of Spring JAR files.

java 6 broke webstart application installation with error 'java.lang.Exception: cache failed for'

After upgrading to the latest java version (Java 6 update 13) a webstart application that was being used in production environments for many years, stopped installing with the following error:
java.lang.Exception: cache failed forhttp://localhost:8080/ReactorStudio/studio/installer.jnlp
at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The application jnlp is downloaded correctly and all the associated jar files. The application also contains a reference to an installer jnlp file that extracts a few files to the local disk the first the application is being run.
Any ideas on what is the problem, or how I could bypass this?
We had a similar issue when upgrading to the latest JRE. Our issue seemed to be related to this bug that should be fixed in 6u14. Perhaps your issue is also related.
The only workaround we found was to clear the webstart cache and launch the application again. In our experience this seems to be the solution to most webstart issues.
Try to remove href="..." from the "jnlp" tag of the "launch.jnlp" file.

Categories