java.lang.UnsupportedClassVersionError - jdk version - java

I developed an API in Eclipse using jdk 1.7.0_03 on the Windows 7 platform. It works fine when deployed on other Windows 7 systems.
On deploying it on a Windows 8 system using jdk 1.6 it gave the following exception:
HTTP Status 500 - Servlet.init() for servlet MediaPlayer-Backend-API threw exception
type Exception report
message Servlet.init() for servlet MediaPlayer-Backend-API threw exception
description The server encountered an internal error that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet MediaPlayer-Backend-API threw exception
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:931)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1822)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
root cause
java.lang.UnsupportedClassVersionError: favorite/api/VideoManager : Unsupported major.minor version 51.0 (unable to load class favorite.api.VideoManager)
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2908)
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
java.lang.Class.forName0(Native Method)
java.lang.Class.forName(Class.java:247)
com.sun.jersey.core.reflection.ReflectionHelper$3.run(ReflectionHelper.java:284)
com.sun.jersey.core.reflection.ReflectionHelper$3.run(ReflectionHelper.java:279)
java.security.AccessController.doPrivileged(Native Method)
com.sun.jersey.spi.scanning.AnnotationScannerListener$AnnotatedClassVisitor.getClassForName(AnnotationScannerListener.java:224)
com.sun.jersey.spi.scanning.AnnotationScannerListener$AnnotatedClassVisitor.visitEnd(AnnotationScannerListener.java:188)
org.objectweb.asm.ClassReader.accept(Unknown Source)
org.objectweb.asm.ClassReader.accept(Unknown Source)
com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:138)
com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner$1.f(FileSchemeScanner.java:86)
com.sun.jersey.core.util.Closing.f(Closing.java:71)
com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:83)
com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scan(FileSchemeScanner.java:71)
com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:226)
com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:142)
com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:104)
com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:78)
com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:89)
com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:696)
com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:674)
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:205)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:376)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:559)
javax.servlet.GenericServlet.init(GenericServlet.java:160)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:931)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1822)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.33 logs.
Apache Tomcat/7.0.33
I referred to this answer and changed the Installed JRE and Compiler compliance level of the API Eclipse project to jdk 1.5.0_15.
Yet on deploying the API I got the same error.
Any help on whats going wrong and how I make the API compatible with all systems?

You are using two different JDK's to run the program. Java is not backward compatible and so you must run on the same version you compiled with.
jdk 1.7.0_03
and
jdk 1.6

If you were able to compile the API in JDK 1.5 then the UnsupportedClassVersionError error couldn't have come up.
Make sure the compiler version settings is correct in Eclipse and also clean up the directory where .class files are generated. Make some trivial changes in some or all the java files using eclipse editor and generate the new class files and check the timestamp of the generated class files / jar before deploying.

Change eclipse java version as jdk 1.7 and compile it. or check VideoManager.class has build by which version ? Get that version and build your project using that version.

Related

FAIL - Application at context path /ProjectName could not be started (java.lang.UnsupportedClassVersionError) [duplicate]

This question already has answers here:
How to fix java.lang.UnsupportedClassVersionError: Unsupported major.minor version
(51 answers)
Closed 5 years ago.
I am deploying my project on a tomcat7 server but I encounter the error stated as the title above. It shows the exception as below:
Jul 13, 2017 10:24:48 AM org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter naviox
java.lang.UnsupportedClassVersionError: org/survey/model/HomeProfile: Unsupported major.minor version 52.0 (unable to load class org.survey.model.HomeProfile)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2892)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1172)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558)
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:224)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.classForName(ClassLoaderServiceImpl.java:242)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1136)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:853)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850)
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:425)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:849)
at org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:75)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:54)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:55)
at org.openxava.jpa.XPersistence.getEntityManagerFactory(XPersistence.java:197)
at org.openxava.jpa.XPersistence.createManager(XPersistence.java:112)
at org.openxava.component.parse.AnnotatedClassParser.obtainManagedClassNamesUsingJPA(AnnotatedClassParser.java:2740)
at org.openxava.component.parse.AnnotatedClassParser.getManagedClassNames(AnnotatedClassParser.java:2655)
at com.openxava.naviox.impl.BaseAllModulesNamesProvider.getAllModulesNames(BaseAllModulesNamesProvider.java:19)
at com.openxava.naviox.impl.AllModulesNamesProvider.getAllModulesNames(AllModulesNamesProvider.java:14)
at com.openxava.naviox.impl.MetaModuleFactory.createAll(MetaModuleFactory.java:27)
at com.openxava.naviox.impl.DB.createModules(DB.java:127)
at com.openxava.naviox.impl.DB.populateDB(DB.java:83)
at com.openxava.naviox.impl.DB.populateDB(DB.java:75)
at com.openxava.naviox.impl.DB.init(DB.java:27)
at com.openxava.naviox.Modules.init(Modules.java:39)
at com.openxava.naviox.web.NaviOXFilter.init(NaviOXFilter.java:22)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:107)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4746)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5399)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1256)
at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:714)
at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:219)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:213)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
I am new to this. Is the exception due to the difference of jdk version? I am using jdk 1.8 and the folder I deployed to is using jdk 1.7. If so, how can I solve the error?
Please help. Thanks in advance.
Your error is because of the difference in the version of the JDK which compiled the source to classes and the JRE which is trying to run it.
A higher version of JRE can run classes compiled with lower version of JDK, however lower version of JRE can't run classes compiled with higher version
In other words, Java is backwards compatible only, which makes sense.
It will result in the same error that you're getting.
If your boss told you to use Java 7, there are 3 options that you can chose.
Don't use it and explain him that Java 7 is no longer supported. https://java.com/en/download/faq/java_7.xml
Use Java 7 to run as well as compile the code.
2nd option will not work if you have third party libraries which were compiled in higher version of JDK or if you have source code which uses Java 8 features. Third party library issue can be resolved by either importing a version of library compiled in the older version of JDK or if you have access to the source code then by compiling it for older version yourself. If you're already using features of Java 8 then you will have to compile using source and target options in Javac to compile source with higher Java features to class file of lower Java version.
It would look something like below.
javac -source 1.8 -target 1.7 HelloWorld.java
When compiling .java into .class, even if you use jdk 1.8, set compliance level to 1.7, or have tomcat run using a jdk 1.8 as well.
If you use javac, specify -source 1.7 -target 1.7. If you use an IDE, find a preference to set to have the same effect.
For example with Eclipse you'll find theese settings, in project/properties/Java compiler.
With NetBeans project/properties/sources/Source-Binary format.

Strange java.lang.ArrayIndexOutOfBoundsException thrown on jetty startup

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)
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.
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".
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
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>

Tomcat 7 javax.el.ELException

I restarted the httpd and tomcat service today, and after doing so. I was greeted with the following message.
I saw this thread http://www.coderanch.com/t/592922/Tomcat/enable-el-api-jar-ver
And did as they told. I checked, and the el-api.jar is there. I checked another server, and tomcat is running great with it as well.
The server is a Centos 6.4 (final) and Tomcat 7.0.23.
I tried everything, even replacing the jar files, but nothing seems to work.
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException: javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:585)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:396)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
root cause
javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found
javax.el.FactoryFinder.newInstance(FactoryFinder.java:101)
javax.el.FactoryFinder.find(FactoryFinder.java:197)
javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:189)
javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:160)
org.apache.jasper.runtime.JspApplicationContextImpl.getExpressionFactory(JspApplicationContextImpl.java:108)
org.apache.jsp.index_jsp._jspInit(index_jsp.java:31)
org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49)
org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:180)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
root cause
java.lang.ClassNotFoundException: com.sun.el.ExpressionFactoryImpl
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1533)
javax.el.FactoryFinder.newInstance(FactoryFinder.java:87)
javax.el.FactoryFinder.find(FactoryFinder.java:197)
javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:189)
javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:160)
org.apache.jasper.runtime.JspApplicationContextImpl.getExpressionFactory(JspApplicationContextImpl.java:108)
org.apache.jsp.index_jsp._jspInit(index_jsp.java:31)
org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49)
org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:180)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.23 logs.
Please, make sure you have both these jars at ${TOMCAT_HOME}/lib
el-api-2.2.jar // jar version could differ
el-impl-2.2.jar
I got the same error today on Tomcat 9.0.21
and as per this bug - https://bz.apache.org/bugzilla/show_bug.cgi?id=64097
It is a known bug with "el-api.jar" and has been fixed in following versions
Fixed in:
master for 10.0.0.0-M1 onwards
9.0.x for 9.0.31 onwards
8.5.x for 8.5.51 onwards
7.0.x for 7.0.100 onwards
Solution :- You can upgrade tomcat to these versions or just bring over the "el-api.jar" from the lib folder of a newer tomcat (which has the fix), place it in your lib folder and restart tomcat.
It would work.

Running RMI client in Tomcat 7 got ClassNotFoundException

I am having some difficulties with RMI and Tomcat. This is the big picture of this project I am working on: the RMI client is called by a Java servlet that runs in Tomcat, the servlet accept user input and pass the parameters to the RMI client. Then the RMI client then calls the RMI server to run the heavy compuation part. The problem is that although everything works fine without hosting the RMI client in the Tomcat server, it doesn't run once I put it in Tomcat.
Here are some configurations:
I DID NOT set up the security manager in the code, I assume that Tomcat will use its own.
//if (System.getSecurityManager() == null) {
// System.setSecurityManager(new SecurityManager());
//}
I also set the permission as following:
$CATALINA_HOME/conf/catalina.policy
grant codeBase "file:${catalina.home}/webapps/MyAPP/WEB-INF/classes/-" {
permission java.security.AllPermission "", ""; };
grant codeBase "file:${catalina.home}/webapps/MyAPP/WEB-INF/lib/-" {
permission java.security.AllPermission "", "";
};
grant codeBase "file:${catalina.home}/webapps/MyAPP/WEB-INF/lib/some-common-3.0.jar" {
permission java.io.FilePermission "*", "read, write";
};
Other than these two configurations, I didn't set any java.rmi.server.codebase or java.security.policy.
I got the following error by submitting the code from RMI client to RMI server:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: mypackage.SomeClass
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:334)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:178)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
at com.sun.proxy.$Proxy19.executeTask(Unknown Source)
at cluster.server.centralservice.CentralManagementServer.submitJob(CentralManagementServer.java:232)
at cluster.server.centralservice.JobSubmitter.runJob(JobSubmitter.java:226)
at cluster.server.centralservice.JobSubmitter.doPost(JobSubmitter.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: mypackage.SomeClass
I have been stuck here for a few days. Most examples I searched online is outdated and do not cover the RMI with Tomcat set up.
Can anybody help? Many thanks.
as the exception says
java.lang.ClassNotFoundException: mypackage.SomeClass
this happens coz RMI is using a seperate class loader which isn't able to see SomeClass .
Add <Loader delegate="true"/> into context.xml file (to Context element) in tomcat/conf directory.
This change fixed a similar issue I faced (not particularly with RMI) but worth a try.

ClassCastException -- Error on Redhat, not on Windows

I have my website running on Tomcat. When I try to access one of my pages to do a status check, it checks on a particular JAR file. On Red Hat 5, but not on Windows, I get the following error:
java.lang.ClassCastException: LoggingPasshashInfo cannot be cast to PasshashInfo
I got this JAR from a third party and am using it just as I got it. According to Apache's tatus page, the RH setup is on Tomcat version 7.0.22 and JVM version 1.6.0_27-b07. Windows is on Tomcat 7.0.19 and JVM 1.6.0_26-b03. Red Hat's Tomcat was upgraded from 6.0.33 over the course of trying to get this fixed.
Anyway, I'm a bit new at this and, aside from getting the setups to look as similar as possible, I'm not sure how to go about solving this. Any help would be fine, and if I've failed to share any important details, let me know. And just to reiterate, the JAR I'm working with is a black box.
Full error:
Java.lang.ClassCastException: com.adobe.adept.fulfillment.test.LoggingPasshashInfo cannot be cast to com.adobe.adept.fulfillment.PasshashInfo
at com.adobe.adept.fulfillment.servlet.Fulfill.<clinit>(Fulfill.java:130)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:127)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1099)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:836)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:135)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
I suspect you have more than one copy of the jar file installed on the Linux server. The result of this could be that the same jar is loaded by multiple classloaders. Classes that would normally be related, but are loaded by unrelated classloaders, are not convertible via a cast. Check carefully for other copies of the jar file -- for example, in Tomcat's top-level "server/lib" directory -- and remove all but one.

Categories

Resources