Исключение приведения класса при развертывании в Liferay DXP - PullRequest
0 голосов
/ 18 мая 2018

Мы получаем следующее сообщение об ошибке при развертывании любого приложения в Liferay DXP 7.

Когда мы очищаем Liferay DXP и затем повторно внедряем, приведенная ниже проблема исправляется.Но проблема этого подхода заключается в том, что после очистки все кэши удаляются, а когда мы повторно развертываем и получаем доступ к сайту, кэши восстанавливаются, но для доступа к любой странице сайта требуется много времени.

[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)

1 Ответ

0 голосов
/ 20 мая 2018

Причину точную невозможно точно определить с помощью предоставленной вами информации.Тем не менее, класс проблемы легко определить:

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

(разделены на строки, чтобы проиллюстрировать идентичное имя класса)

Всякий раз, когда класс не может быть приведен к типу или законный суперкласс / интерфейс, вы имеете дело с дублированным кодом: для загрузчика классов доступны две версии класса с одинаковым именем, и система выбирает обе.

В качестве ошибкисообщение содержит только имя класса, а не его загрузчик, первый взгляд на сообщение об ошибке не имеет смысла.Зная, что класс уникально описывается своим пакетом, именем и , его загрузчик классов приводит вас к основной причине.

Определите ваши модули и убедитесь, что для com.fsvps.clientPortal.domain.common.UserContext есть только одна опциядоступны.

Редактировать : Отвечая на ваши комментарии - не зная деталей вашего развертывания, нет другого способа помочь вам, кроме диких догадок.Пожалуйста, добавьте больше информации в свой вопрос, если следующее дикое предположение не помогает:

Имя класса, UserContext, предполагает, что вы можете хранить его где-нибудь, например, в сеансе.Это предотвратит выгрузку исходного класса, когда вы удаляете плагин. Обратите внимание, что между неразвертыванием кода и объектами сбора мусора существует огромная разница : сборщик мусора может происходить только тогда, когда больше нет ссылок.

Если вы развернете обновленную версию вашего плагина, старые и существующие объекты по-прежнему будут ссылаться на ранее загруженный класс UserContext, в то время как новый код пытается присвоить его новой ссылке UserContext.Несмотря на то, что оба могут быть идентичными в реализации, это разные классы, которые просто разделяют имя.

Вы не можете долго хранить ссылки на код, который может быть развернут, и ожидать, что он останется пригодным для использования.Быстрое исправление (если вы развертываете модули OSGi) может заключаться в извлечении стабильных и долго используемых классов в свой собственный пакет, который вы не будете повторно развертывать.Или замените хранимые в сеансе объекты (при условии, что это так) классами времени выполнения Java, например, Map встроенных типов, и создайте объект UserContext из этих типов всякий раз, когда вам это нужно.

...