CODEWITHSUNDEEP
liferayclasscastexception
Ankur Mehrotra
Ankur Mehrotra

Reputation: 29

Class Cast Exception coming while Deploying in Liferay DXP

We are getting following below error when we deploy any application in Liferay DXP 7.

When we clean the Liferay DXP and then redeploy the below issue gets fixed. But the problem with this approach is that all the caches gets deleted after cleaning and when we redeploy and access the site , the caches gets recreated but it takes lot of time to access any page on the site.

[2018-05-17 10:58:33,113] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.service.common.ProgramFilterPopulator] - Retrieving logged in user
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Portlet mode view and debug mode = false
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Checking to see if invalid filter view should be shown
[2018-05-17 11:07:40,859] [DEBUG] [] [] [http-nio-5443-exec-2] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Entering
[2018-05-17 11:07:40,859] [WARN] [] [] [http-nio-5443-exec-2] [org.springframework.web.portlet.DispatcherPortlet] - Handler execution resulted in exception - forwarding to resolved error view
java.lang.ClassCastException: com.fsvps.clientPortal.domain.common.UserContext cannot be cast to com.fsvps.clientPortal.domain.common.UserContext
        at com.fsvps.clientPortal.domain.common.UserContext$$FastClassBySpringCGLIB$$818d2483.invoke(<generated>)
        at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
        at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
        at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
        at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
        at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
        at com.fsvps.clientPortal.domain.common.UserContext$$EnhancerBySpringCGLIB$$830ac420.setIpAddress(<generated>)
        at com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor.preHandle(UserContextInitializationInterceptor.java:93)
        at org.springframework.web.portlet.handler.HandlerInterceptorAdapter.preHandleRender(HandlerInterceptorAdapter.java:72)
        at org.springframework.web.portlet.DispatcherPortlet.doRenderService(DispatcherPortlet.java:739)
        at org.springframework.web.portlet.FrameworkPortlet.processRequest(FrameworkPortlet.java:537)

Upvotes: 1

Views: 510

Answers (1)

Olaf Kock
Olaf Kock

Reputation: 48057

The exact cause is impossible to pinpoint with the information you give. However, the class of problem is easy to identify:

java.lang.ClassCastException: 
   com.fsvps.clientPortal.domain.common.UserContext cannot be cast to
   com.fsvps.clientPortal.domain.common.UserContext

(separated to lines to illustrate the identical class name)

Whenever a class can't be typecasted to itself or a legitimate superclass/interface, you're dealing with duplicate code: There are two versions of the class with the same name available to the classloader, and the system is choosing both.

As the error message just contains the name of the class, not its classloader, a first glance at the error message doesn't make sense. Knowing that a class is uniquely described by its package, name, and its classloader leads you to the root cause.

Identify your modules and make sure that there's only one option for com.fsvps.clientPortal.domain.common.UserContext available.

Edit: Answering to your comments - without knowing your deployment details, there's no way to help you other than wild guesses. Please add more information to your question if the next wild guess doesn't help:

The name of the class, UserContext, suggests that you might store it somewhere, e.g. in a session. Doing so will prevent the original class from unloading when you're undeploying your plugin. Note that there is a huge difference between undeploying code and garbage collecting objects: GC can only happen, when there is no more reference.

If you deploy an updated version of your plugin, the old and existing objects still are referencing the previously loaded UserContext class, while the new code is trying to assign it to a new UserContext reference. Even though, both might be identical in implementation, they are different classes that just share the name.

You can't keep long living references to code that might undeploy, and expect them to stay usable. A quick fix (if you're deploying OSGi modules) might be to extract stable and long-used classes into its own bundle that you won't redeploy. Or replace session stored objects (assuming that this is it) with Java runtime classes, e.g. Map of built-in types, and build a UserContext object from those types whenever you need it.

Upvotes: 1

Related Questions