Liferay DXP部署时出现Class Cast Exception异常问题

What's Causing This Weird Exception? #

That java.lang.ClassCastException: com.fsvps.clientPortal.domain.common.UserContext cannot be cast to com.fsvps.clientPortal.domain.common.UserContext error looks confusing at first glance—how can a class not cast to itself? The root cause is classloader conflict:

• Liferay DXP uses a modular classloading system where each portlet/application might have its own isolated classloader
• If the UserContext class gets loaded by multiple classloaders, the JVM treats them as entirely separate Class objects (even with the same fully qualified name)
• When Spring AOP (via CGLIB proxy) generates a proxy class that's loaded by a different classloader than the original UserContext, this cast exception gets thrown

Optimized Solutions (No Full Cache Purge Needed) #

Here are targeted fixes, ordered by effectiveness:

1. Load UserContext via the Global Classloader #

If UserContext is a shared core class used across multiple apps, move it to Liferay's global classpath:

• Copy the JAR containing UserContext to [Liferay_Home]/tomcat/lib/ext
• Restart Liferay once (no need for repeated restarts for future deployments)
• This ensures all apps use the same global classloader to load the class, eliminating duplicate loads

2. Adjust Portlet Classloader Isolation #

If UserContext is specific to your application, tweak the portlet's classloader configuration:

• Add this to your liferay-portlet.xml:

  <portlet>
    <portlet-name>your-portlet-name</portlet-name>
    <!-- Existing config -->
    <class-loader>portal</class-loader>
  </portlet>
  

• Alternatively, configure your osgi.bnd file to enforce classloader dependencies:

  Import-Package: com.fsvps.clientPortal.domain.common
  DynamicImport-Package: *
  

• This forces your portlet to use the portal's global classloader for UserContext, avoiding local classloader duplication

3. Clear Specific Caches (Not All) #

If you prefer not to modify code/configs, clear only the classloader-related caches instead of the entire cache pool:

• Log into the Liferay Control Panel, go to Configuration > Server Administration
• Switch to the Cache Management tab
• Locate and clear these caches:
  • com.liferay.portal.kernel.servlet.PortalClassLoaderPool
  • com.liferay.portal.kernel.classloader.ClassLoaderPool
• Redeploy your application afterward—this only clears classloader caches, leaving your site content cache intact

4. Tweak Spring AOP Proxy Settings #

If the exception stems from Spring CGLIB proxies, switch to JDK dynamic proxies:

• Add this to your Spring XML config:

  <aop:config proxy-target-class="false"/>
  

• Or use the annotation-driven approach:

  @EnableAspectJAutoProxy(proxyTargetClass = false)
  

• JDK proxies are interface-based and don't generate subclass proxies, which avoids classloader conflicts with proxy classes

Verification #

After applying any of these fixes, redeploy your application and check logs for the ClassCastException. You should see the error gone, and your site's page load speed won't take a hit from rebuilding full cache.

内容的提问来源于stack exchange，提问作者Ankur Mehrotra