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.
Related
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.
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.
I have a workaround for my specific error, which is to add the path C:\ColdFusion10\cfusion\wwwroot\WEB-INF\classes to the ColdFusion Class Path setting. However, I'm not sure why that is necessary. Details below:
I have been using a legacy [I don't know who wrote it or where it came from] Java class in ColdFusion 9 to help read and parse mailbox files. When I upgraded to ColdFusion 10 it stopped working. Here's a brief example:
<cfset archive = createObject("Java", "its.util.MBoxReader")>
<cfdump var="#archive#">
On CF9 that works. On CF10 it produces this message:
Object instantiation exception.
An exception occurred while instantiating a Java object. The class must not be an interface or an abstract class. Error: javax/mail/Store.
Here's the stack trace:
java.lang.NoClassDefFoundError: javax/mail/Store at
java.lang.Class.getDeclaredFields0(Native Method) at
java.lang.Class.privateGetDeclaredFields(Class.java:2317) at
java.lang.Class.privateGetPublicFields(Class.java:2350) at
java.lang.Class.getFields(Class.java:1378) at
coldfusion.runtime.java.ObjectHandler.Initialize(ObjectHandler.java:35)
at
coldfusion.runtime.java.ObjectHandler.(ObjectHandler.java:30)
at
coldfusion.runtime.java.ReflectionCache.get(ReflectionCache.java:38)
at coldfusion.runtime.java.JavaProxy.(JavaProxy.java:35) at
coldfusion.runtime.java.JavaProxyFactory.getProxy(JavaProxyFactory.java:121)
at coldfusion.runtime.ProxyFactory.getProxy(ProxyFactory.java:65) at
coldfusion.runtime.CFPage.createObjectProxy(CFPage.java:5757) at
coldfusion.runtime.CFPage.CreateObject(CFPage.java:5720) at
coldfusion.runtime.CFPage.CreateObject(CFPage.java:5654) at
coldfusion.runtime.CFPage.CreateObject(CFPage.java:5629) at
coldfusion.runtime.CFPage.CreateObject(CFPage.java:5576) at
cfindex2ecfm915725705.runPage(C:\ColdFusion10\cfusion\wwwroot\mbox\index.cfm:1)
at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:244) at
coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:444) at
coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at
coldfusion.filter.IpFilter.invoke(IpFilter.java:64) at
coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:449)
at
coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48)
at
coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
at coldfusion.filter.PathFilter.invoke(PathFilter.java:112) at
coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:30) at
coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:94) at
coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:79)
at
coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at
coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46) at
coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at
coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62) at
coldfusion.CfmServlet.service(CfmServlet.java:219) at
coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at
coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
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:224)
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:98)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:414)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
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:722) Caused by:
java.lang.ClassNotFoundException: javax.mail.Store at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1533)
... 55 more
However, if I add this to my test page, CF10 is able to find & load javax.mail.Store:
<cfset store = createObject("Java", "javax.mail.Store")>
<cfdump var="#store#">
javax.mail.Store is present in the mail.jar files included with ColdFusion and are located in C:\ColdFusion9\lib and C:\ColdFusion10\cfusion\lib on CF9 and CF10, respectively.
MboxReader.class is located in C:\ColdFusion9\wwwroot\WEB-INF\classes\its\util and C:\ColdFusion10\cfusion\wwwroot\WEB-INF\classes\its\util (CF9 and CF10, respectively).
If I manually add C:\ColdFusion10\cfusion\wwwroot\WEB-INF\classes to the ColdFusion Class Path in the CF administrator it works.
I'm not sure why ColdFusion can find the class, but the MboxReader class cannot unless I add the classpath. According to About ColdFusion, Java, and J2EE, ColdFusion should load the classes in WEB-INF/classes.
Update:
The parent class loader of the archive object:
coldfusion.bootstrap.BootstrapClassLoader
The parent class loader of the javax.mail.Store object:
org.apache.catalina.loader.WebappClassLoader
It seems some class depends on javax.mail.Store, but it cannot find it at runtime. If you could post the full stacktrace we can see which class it is.
Try to see how the chain of classloaders is set up in coldfusion, WEB-INF/classes is included by default, and then all jars of WEB-INF/lib.
EE servers can be configured to look first on the server and only then on WEB-INF/classes / WEB-INF/lib. This configuration is both server and application specific, with different defaults per server (Tomcat defaults are different than websphere, etc.).
If Coldfusion uses Java 7 you can use JHades to print the classloader chain and do some queries on the classpath, to see where the different versions of the several problematic classes are.
Try to answer these questions, you can always post partial findings:
Which class is not finding java.mail.Store
In which class loader does the class that is throwing the exception resides
For the problematic classes (javax.mail.Store and the class that is not finding it) post the different versions present on the classpath, per classloader (JHades could help with that)
How is the classloader chain setup configured, what are the configured priorities etc.
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.
I am seeing the following messages in the logs after each redeploys.
INFO: Reloading Context with name [/x1Application] has started
SEVERE: The web application [/x1Application] appears to have started a thread named [Mojarra-WebResourceMonitor-1-thread-1] but has failed to stop it. This is very likely to create a memory leak.
SEVERE: The web application [/x1Application] appears to have started a thread named [Hector.me.prettyprint.cassandra.connection.CassandraHostRetryService-1] but has failed to stop it. This is very likely to create a memory leak.
Eventually after 1-2 hot deploys the server stops responding & I get the PermGen space error
17 Mar, 2012 1:40:01 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw exception [The HTTP Monitor server side component intercepted and rethrew an error while processing a JSP or servlet. Please see the stack trace under the root cause message below to identify the problem.] with root cause
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
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:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:182)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
17 Mar, 2012 1:40:12 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw exception [The HTTP Monitor server side component intercepted and rethrew an error while processing a JSP or servlet. Please see the stack trace under the root cause message below to identify the problem.] with root cause
java.lang.OutOfMemoryError: PermGen space
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
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:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:182)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
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)
How can I get more information about the source of bug?
I'd report it to Hector guys. It's their bug that their code is not properly shutting down running threads on webapp's shutdown. In the meanwhile, you could consider to pick a better development server (favourite is Glassfish; it hotdeploys in a subsecond) or to install JRebel to transform Tomcat into a real hotdeployer instead of a hotrestarter.
As to the background information about Tomcat's memory leak protection, read the following wikis:
Tomcat wiki - Memory leak protection
Tomcat wiki - How to deal with out of memory
Shortly I had to deal with a leaking Thread named "Mojarra-WebResourceMonitor-1-thread-1" on
Apacht Tomcat 8.0.26 with
Mojarra 2.2.12
in my web app using servlet sepc 3.0.
The root cause was that two instances of com.sun.faces.config.ConfigureListener had been added to the ServletContext.
First instance (A) was added by Tomcat's container SCI
org.apache.jasper.servlet.JasperInitializer.onStartup(...)
as it is configured in javax.faces-2.2.12.jar!/META-INF/jsf_core.tld
Second instance (B) was added by
com.sun.faces.config.FacesInitializer.onStartup(...)
Workaround was to prevent JapserInitializer from invokation by editing my web app context.xml and add the containerSciFilter attribute to the context element:
<Context containerSciFilter="org.apache.jasper.servlet.JasperInitializer|org.apache.tomcat.websocket.server.WsSci">
Both SCIs are not needed for my web app. So this work around won't help if you depend on JSP and JSF.
This is what happend wrong here:
On Servlet initialization, tomcat called
A.contextInitialized(...)
Initialize JSF
Start the threadPool
B.contextInitialized(...)
As JSF is running ...nothing to do
On Shutdown, tomcal calls:
B.contextDestroyed(...)
Shutdown JSF
Don't know of any threadPool as I haven't started one.
A.contextDestroyed(...)
As JSF is stopped, nothing to do.
Thus As' threadPool remains up and running, preventing GC on WebAppClassloader.
But whose fault is this?
Did Tomcat fail to reject multiple listeners of same Class?
Did JSF Mojarra fail to stop the threadPool due to its' implication of threadPool absence when there's no JSF up and running?
Is it wrong that the listener is declared twice:
Programmaticalli thru SCI
Declared in core TLD taglib.
Edit: It was problematic for me to completely skip the JasperInitializer. I had to remove it from containerSciFilter and add javax.faces-*.jar to Tomcat tldSkip filter like this:
<JarScanner>
<JarScanFilter defaultPluggabilityScan="false"
pluggabilityScan="${tomcat.util.scan.StandardJarScanFilter.jarsToScan}, javax.faces-*.jar"
tldSkip="${tomcat.util.scan.StandardJarScanFilter.jarsToSkip}, , javax.faces-*.jar" />
</JarScanner>