Liferay 6 Использование общего уровня Service Builder Ошибка - BeanLocatorException - BeanLocator не был установлен

Question

Мы пытаемся использовать Liferay Service Builder в качестве общего слоя для всех наших портлетов. Мы создали отдельный общий проект портлета, в котором мы создаем сервис с использованием service.xml. Он генерирует для нас файл service.jar. Мы копируем этот jar-файл во все портлеты WEB-INF / lib dir.

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

14:43:17,447 ERROR [jsp:154] com.liferay.portal.kernel.bean.BeanLocatorException: BeanLocator has not been set
    at com.liferay.portal.kernel.bean.PortletBeanLocatorUtil.locate(PortletBeanLocatorUtil.java:40)
    at com.cogs.common.service.CourseLocalServiceUtil.getService(CourseLocalServiceUtil.java:223)
    at com.cogs.common.service.CourseLocalServiceUtil.getCoursesCount(CourseLocalServiceUtil.java:187)
    at org.apache.jsp.jsps.course.course_005fview_jsp._jspService(course_005fview_jsp.java:542)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
    at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
    at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)

Я уверен, что этот подход должен работать без проблем. Но нашел несколько человек, жалующихся на это на форумах LifeRay, но не нашел никакого решения еще. Пожалуйста, дайте нам знать, если вы нашли способ использовать построитель сервисов в качестве общего слоя, и он сработал для вас.

Мы используем maven для создания всех проектов портлетов.

Liferay версия 6.0.5 И мы используем Spring Portlet MVC для разработки нашего портлета.

Answer 1

Вам необходимо построить сервис и развернуть (Portlet-Hook), который требуется для вашего текущего портлета, вы можете узнать его, увидев его имя в файле liferay-plugin-package.properties как:

required-deployment-contexts=[Portlet-Hook name]

Answer 2

Я пробовал все, что написано на этой странице, но у меня ничего не получалось, пока я не добавил версию проекта

до maven-pluginname в pom :

            <configuration>
                <autoDeployDir>${liferay.auto.deploy.dir}</autoDeployDir>
                <appServerDeployDir>${liferay.app.server.deploy.dir}</appServerDeployDir>
                <appServerLibGlobalDir>${liferay.app.server.lib.global.dir}</appServerLibGlobalDir>
                <appServerPortalDir>${liferay.app.server.portal.dir}</appServerPortalDir>
                <liferayVersion>${liferay.version}</liferayVersion>
                <pluginType>portlet</pluginType>
                <pluginName>${project.artifactId}-${project.version}</pluginName>
            </configuration>

и liferay-plugin-package.properties :

   artifactId-version-deployment-context=artifactId-version

например:

   portlet-sample-1.0-deployment-context=portlet-sample-1.0

, где artifactId = пример портлета

и версия = 1,0

В конце концов, я построил службы и развернул войну.

Я пришел к решению, потому что отладил:

com.liferay.portal.kernel.bean.PortletBeanLocatorUtil

, где

BeanLocator beanLocator = getBeanLocator(servletContextName);

Вызывается

, который всегда возвращает ноль без номера версии ...

Надеюсь, кому-то это поможет.

Answer 3

У нас было требование использовать нечто подобное: иметь портлет (скажем, Source-portlet), службы которого будут использоваться другими портлетами.

Итак, мы переехали в сгенерированном sourceportlet-service.jar из папки WEB-INF/lib до {tomcat_home}/lib/ext исходного портлета находятся другие jar-файлы, такие как portlet-service.jar и т. Д.

Недостатком этого подхода является всякий раз, когда происходит изменение вИсходный портлет, нам нужно было бы перезапустить сервер.

Если другие портлеты являются вашими пользовательскими подключаемыми портлетами подключаемых модулей, другим подходом было бы скопировать сгенерированный sourceportlet-service.jar в WEB-INF/lib другого портлета.Этот подход не работает, если вы используете службу в перехватчике JSP.

Надеюсь, это поможет.

Answer 4

Мне было трудно найти решение этой ошибки, поэтому я опубликую то, что мы сделали.Имя портлета изменилось, собрал сервис и при запуске портлет выдает ту же ошибку:

com.liferay.portal.kernel.bean.BeanLocatorException: BeanLocator has not been set for servlet context

В нашем случае нам пришлось удалить файл jar из ../docroot/WEB-INF/lib/portlet-service.jar

Answer 5

У меня была похожая проблема при создании портлета maven.Сначала я сделал портлет, а затем поставил service.xml

Проблема заключалась в том, что генератор искал имя портлета, которого там не было, я решил создать экспликацию имени портлета, который я хотел, чтобы генратор искал

в частности, для этого два pom-узла должны быть равны

project.artifatctId = (для этого liferay создает локатор bean-компонента)

и

project.build. (плагин liferay) .configuration.pluginName = внутреннее имя портлета для генератора

, например, небольшая выдержка из моего pom.xml

<modelVersion>4.0.0</modelVersion>
<groupId>io.endeios</groupId>
<artifactId>ShowTheCats-portlet</artifactId><!-- ONE -->
<packaging>war</packaging>
<name>ShowTheCats Portlet</name>
<version>1.0-SNAPSHOT</version>
<build>
    <plugins>
        <plugin>
            <groupId>com.liferay.maven.plugins</groupId>
            <artifactId>liferay-maven-plugin</artifactId>
            <version>${liferay.maven.plugin.version}</version>
            <executions>
                <execution>
                    <phase>generate-sources</phase>
                    <goals>
                        <goal>build-css</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <autoDeployDir>${liferay.auto.deploy.dir}</autoDeployDir>
                <appServerDeployDir>${liferay.app.server.deploy.dir}</appServerDeployDir>
                <appServerLibGlobalDir>${liferay.app.server.lib.global.dir}</appServerLibGlobalDir>
                <appServerPortalDir>${liferay.app.server.portal.dir}</appServerPortalDir>
                <liferayVersion>${liferay.version}</liferayVersion>
                <pluginType>portlet</pluginType>
                <pluginName>ShowTheCats-portlet</pluginName><!-- TWO -->
            </configuration>
        </plugin>

ONE иДВА должны быть одинаковыми

Answer 6

Предыдущий ответ Мартина Гамулина правильный. Если у вас есть два отдельных веб-приложения, одно для портлетов Spring, а другое с вашим Service Builder (что, по-видимому, является правильным способом выполнения действий в Liferay), то вам нужно убедиться, что ваши портлеты Spring не ссылаются на ваши классы ServiceBuilder во время инициализации .

Если это происходит в зависимости от порядка, в котором сервер приложений создает экземпляры ваших веб-приложений (а в Tomcat вы не можете указать порядок запуска), исключение BeanLocatorException будет происходить каждый раз, когда веб-приложение с портлетами развертывается перед веб-приложением компоновщика.

В нашем случае это означало перемещение вызова XxxLocalServiceUtil.createXxx(0) из конструктора контроллера портлета в соответствующие методы.

Answer 7

Я сделал следующее, чтобы решить вышеуказанную проблему:

1. Установите правильное значение свойства config plugin pluginName в pom.xml

       <plugin>
           <groupId>com.liferay.maven.plugins</groupId>
           <artifactId>liferay-maven-plugin</artifactId>
           <version>${liferay.version}</version>
           <configuration>
               <autoDeployDir>${liferay.auto.deploy.dir}</autoDeployDir>
               <appServerPortalDir>${liferay.app.server.portal.dir}</appServerPortalDir>
               <liferayVersion>${liferay.version}</liferayVersion>
               <pluginType>portlet</pluginType>
               <pluginName>XXXX-portlet</pluginName>
           </configuration>
       </plugin>
   

2. При желании установите свойство XXXX-portlet-deploy-context-context в файле свойств подключаемого модуля liferay или в файле portlet.properties

XXXX-portlet-deployment-context=XXXX-portlet

3. Перестроить услуги
4. Проверьте, содержит ли сгенерированный ClpSerializer.java правильный контекст

`public static String getServletContextName () { if (Validator.isNotNull (_servletContextName)) { return _servletContextName; }

    synchronized (ClpSerializer.class) {
        if (Validator.isNotNull(_servletContextName)) {
            return _servletContextName;
        }

        try {
            ClassLoader classLoader = ClpSerializer.class.getClassLoader();

            Class<?> portletPropsClass = classLoader.loadClass(
                    "com.liferay.util.portlet.PortletProps");

            Method getMethod = portletPropsClass.getMethod("get",
                    new Class<?>[] { String.class });

            String portletPropsServletContextName = (String) getMethod.invoke(null,
                    "XXXX-portlet-deployment-context");

            if (Validator.isNotNull(portletPropsServletContextName)) {
                _servletContextName = portletPropsServletContextName;
            }
        } catch (Throwable t) {
            if (_log.isInfoEnabled()) {
                _log.info(
                    "Unable to locate deployment context from portlet properties");
            }
        }

        if (Validator.isNull(_servletContextName)) {
            try {
                String propsUtilServletContextName = PropsUtil.get(
                        "XXXX-portlet-deployment-context");

                if (Validator.isNotNull(propsUtilServletContextName)) {
                    _servletContextName = propsUtilServletContextName;
                }
            } catch (Throwable t) {
                if (_log.isInfoEnabled()) {
                    _log.info(
                        "Unable to locate deployment context from portal properties");
                }
            }
        }

        if (Validator.isNull(_servletContextName)) {
            _servletContextName = "upay-portlet";
        }

        return _servletContextName;
    }
}`

5. Разверните войну, проверьте правильное имя контекста и журналы войны.

Answer 8

Кажется, что не работает для примера портлета Календарь, который является частью источника плагинов Liferay 6.2.

Ошибка размещена на

https://www.liferay.com/community/forums/-/message_boards/message/38041984

Answer 9

У меня тоже была такая же проблема.Я поместил следующий код в файл портлетов liferay-plugin-package.properties, который использует сервисный уровень общего портлета.У меня это сработало.

required-deployment-contexts=common-portlet

Лучше скопировать файл service.jar в tomcat / lib / ext вместо всех портлетов WEB-INF / lib.

Answer 10

Поскольку вы используете maven, постарайтесь, чтобы ваше военное имя совпадало с именем вашего проекта портлета. После отладки я обнаружил, что ClpSerializer определяет _servletContextName, что равно <artifactId> военного проекта. Если вы развернете артефакт с именем artifactId-1.0.0-snapshot.war, контекст будет создан с этим именем, но код, сгенерированный servicegen, ожидает, что он будет artifactId. Проверьте с помощью ClpSerializer.