开发者

ClassCastException -- Error on Redhat, not on Windows

开发者 https://www.devze.com 2023-04-10 20:40 出处:网络
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:

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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号