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

Ответ 1

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

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

Ответ 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);

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

в частности, для этого два узла 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 и TWo должны быть одинаковыми

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

required-deployment-contexts=common-portlet

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

Ответ 10

Кажется, что не работает для образца календаря, который является частью источника Plugins 6.2 для liferay.

Ошибка отправлена ​​на

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

Ответ 11

Я решил сделать следующее:

• Установить плагин config property 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>
  

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