Strange java.lang.ArrayIndexOutOfBoundsException thrown on jetty startup

java jetty maven-jetty-plugin

28,676

Solution 1

For your 2 errors ..

javax.servlet.ServletException: jersey-serlvet

This means you have a typo in your WEB-INF/web.xml

As for this one ..

java.lang.ArrayIndexOutOfBoundsException: 6241
    at org.objectweb.asm.ClassReader.<init>(Unknown Source)

I've seen similar ones when using an old version of asm.jar with newer compiled Java bytecode.

For Java 15 bytecode, use asm 7.3.1+
For Java 14 bytecode, use asm 7.2+
For Java 13 bytecode, use asm 7.1+
For Java 12 bytecode, use asm 7.1+
For Java 11 bytecode, use asm 7.0+
For Java 10 bytecode, use asm 6.1+
For Java 9 bytecode, use asm 6.0+
For Java 8 bytecode, use asm 5.0.1+
For Java 6 or Java 7 bytecode, (Use asm 3.1 if you must, but know that asm 5.x is also going to work here too)

Ensure that your asm.jar (or org.objectweb.asm.jar) is current.

There is a slightly less common issue where the class itself is bad. Sometimes seen with classes that are compiled in one JDK (such as IBM) and then run on another Java (like Sun/Oracle).

A real world example of this would be the icu4j-2.6.1.jar and its com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class jar entry.

Solution 2

Use newer version of jetty-maven-plugin.

More information --> Bug 419801 - Upgrade to asm5 for jdk8

So, edit your pom.xml like this：

<plugin>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>9.3.0.M2</version>
</plugin>

Note the groupId is "org.eclipse.jetty".

Solution 3

In my case, I am using ASM library version and that not support java 8 lambda expression, so either you change ASM library to support java 8 or change your code.

In my case I am using java 8 lambda expression for iterating and I replaced it with for loop

Solution 4

I came across similar issue when maintaining legacy code.

Servlet.init() for servlet JerseyServlet threw exception

type Exception report

message Servlet.init() for servlet JerseyServlet threw exception

description The server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Servlet.init() for servlet JerseyServlet threw exception
    org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
    org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
    org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423)
    org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079)
    org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
    org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
    java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    java.lang.Thread.run(Thread.java:745)
root cause

java.lang.ArrayIndexOutOfBoundsException
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.65 logs.

I fixed it with reducing the package scanning scope in web.xml. E.g., removing the package_with_too_many_classes below in param-value tag fixed the issue.

<servlet>
   <servlet-name>JerseyServlet</servlet-name>
   <servlet-class>com.sun.jersey.spi.spring.container.servlet.SpringServlet</servlet-class>
   <init-param>
       <param-name>com.sun.jersey.config.property.packages</param-name>
       <param-value>package_with_too_many_classes;package_with_approciate_number_of_classes;org.codehaus.jackson.jaxrs</param-value>
   </init-param>
   <load-on-startup>2</load-on-startup>
 </servlet>

View more solutions

28,676

Author by

Jakozaur

Updated on June 10, 2020

Comments

Jakozaur about 4 years

Whenever I deploy jetty application I hit this issue. Looks like some jar or class is broken.

Colleagues compiling exactly same code, doesn't hit the issue. Even if the deploy to the same computer. (we use git and maven)
Deleting local maven repository ~/.m2 and rebuilding doesn't help.
Can run same jetty app locally without any issues.
My initial suspect was that some jar is broken. Tried jar tvf $every_jar and haven't found anything.

Any ideas how can I debug this? Looks really mysterious and I suspect is that some file get corrupted.

Stack trace:
2014-10-21 13:29:25.123:WARN:oejw.WebAppContext:Failed startup of context o.e.j.w.WebAppContext{/,file:/XYZ/},/XYZ/webapps/root
javax.servlet.ServletException: jersey-serlvet
        at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:553)
        at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:344)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
        at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:791)
        at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
        at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
        at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
        at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
        at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
        at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
        at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
        at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
        at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
        at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
        at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:615)
        at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
        at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
        at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
        at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
        at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
        at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
        at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
        at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
        at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
        at org.eclipse.jetty.server.Server.doStart(Server.java:282)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
        at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1274)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1197)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.eclipse.jetty.start.Main.invokeMain(Main.java:473)
        at org.eclipse.jetty.start.Main.start(Main.java:615)
        at org.eclipse.jetty.start.Main.main(Main.java:96)

followed by

Caused by:
java.lang.ArrayIndexOutOfBoundsException: 6241
        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.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:133)
        at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner$1.f(FileSchemeScanner.java:86)
        at com.sun.jersey.core.util.Closing.f(Closing.java:71)
        at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:83)
        at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:80)
        at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:80)
        at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scan(FileSchemeScanner.java:71)
        at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:223)
        at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:139)
        at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
        at com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:104)
        at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:78)
        at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:89)
        at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:700)

Jakozaur over 9 years

Use Java 7 and asm 3.1.
Joakim Erdfelt over 9 years

What you use for your JVM is irrelevant to bytecode scanning, the class that is causing the failure could be of a bytecode higher than your JVM. (in other words, the class that is being tripped up could be compiled for Java 8)
Jonik almost 9 years

Thanks, this solved it for me! See available jetty-maven-plugin versions in Maven Central.
Holger over 7 years

The features that are not handled by ASM 3, are already defined in Java 7 and even if javac doesn’t use them, you might encounter them at runtime. There’s no sense in recommending using an outdated version anyway. Just use ASM 5 for all versions…
jla over 7 years

This worked in my case. I had added new non-servlet classes in a sub-package. I changed their package path and the errors went away.
user155 over 5 years

I don't use asm library. It happens with Android Studio. And only with release build variant, debug is built fine
Joakim Erdfelt over 5 years

@user155 bytecode scanning with asm on android should not work. as the bytecode isn't java anymore when on Android.