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

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

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

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

в 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);

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

Я надеюсь, что кто-то поможет это.

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

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

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

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

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

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

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

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

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

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

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

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

Проблема заключалась в том, что генератор искал имя портлета, которого там не было. Я решил указать имя портлета, которое я хотел, чтобы генератор искал.

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

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

и

project.build.(liferay plugin).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>

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

Проблема с BeenLocator с моим портлетом spring для меня заключалась в том, что контекст весны моего портлета инициализировался раньше, чем контекст весны liferay.

Я использовал ClassName className = ClassNameLocalServiceUtil.getClassName(JournalArticle.class.getName()); в своем конструкторе. Контекст LIferay не был загружен, отсюда и ошибка. Я переместил этот фрагмент кода, чтобы он вызывался, когда (только в этот раз) первый запрос нуждался в этом. Проблема была решена.

Так что не зависьте от lifery при инициализации вашего портлета, сделайте какую-то "ленивую" привязку зависимостей к liferay.

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

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

required-deployment-contexts=common-portlet

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

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

1. Установите для свойства конфигурации плагина 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-deployment-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. Разверните войну, проверьте имя войны и журналы на предмет правильного имени контекста.