Liferay 6 utilisant Common Service Builder layer Error-BeanLocatorException-BeanLocator n'a pas été défini

vous devez construire-service et déployer le (Portlet-Hook) qui est requis pour votre portlet actuel, vous pouvez le connaître par voir son nom dans liferay-plugin-package.propriétés du fichier:

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

j'ai essayé ce qui est écrit sur la page, mais rien n'a fonctionné pour moi, jusqu'à ce que j'ai ajouté la version du projet

maven-pluginname en 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>

et liferay-plugin-paquet.propriétés:

   artifactId-version-deployment-context=artifactId-version

par exemple:

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

où artifactId = portlet-exemple

et version = 1,0

après tout j'ai construit des services, et j'ai redéployé mes guerre.

je suis arrivé à la solution parce que j'ai débogué:

com.liferay.portail.noyau.haricot.PortletBeanLocatorUtil

où

BeanLocator beanLocator = getBeanLocator(servletContextName);

est appelé qui renvoie toujours null sans numéro de version...

j'espère que quelqu'un les aide.

j'ai eu du mal à trouver une solution à cette erreur donc je vais poster ce que nous avons fait. Le nom de la portlet changé, construit le service et lors de l'exécution de la portlet jette la même erreur:

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

Dans notre cas, nous avons dû supprimer le fichier jar de ../ docroot/WEB-INF/lib / portlet-service.jar

nous avions une exigence d'utiliser quelque chose de similaire: avoir un portlet (disons Source-portlet) dont les services seront utilisés par d'autres portlets.

donc nous déplacé l'généré sourceportlet-service.jar à partir de la Source de portlet WEB-INF/lib{tomcat_home}/lib/ext dossiers étaient d'autres jarres comme portlet-service.jar etc résident.

le côté négatif de cette approche est que chaque fois qu'il y a un changement dans le port-source, nous devrions redémarrer le serveur.

si l'autre portlet sont votre plugin personnalisé portlets qu'une autre approche serait de copier le générés sourceportlet-service.jar vers un autre portlet WEB-INF/lib. Cette approche ne fonctionne pas si vous utilisez le service dans un crochet JSP.

J'espère que cela vous aidera.

la réponse précédente de Martin Gamulin est correcte. Si vous avez deux applications web séparées, l'une pour les portlets Spring et l'autre avec votre Service Builder (qui semble être la bonne façon de faire les choses à Liferay), alors vous devez vous assurer que vos portlets Spring ne font pas référence à vos classes ServiceBuilder lors de l'initialisation.

s'ils le font alors en fonction de l'ordre dans lequel votre serveur app instancie votre webapps (et dans Tomcat vous ne pouvez pas spécifier un ordre de démarrage), le BeanLocatorException se produira à chaque fois que le portlets webapp se déploie avant le constructeur webapp.

dans notre cas cela signifiait déplacer un XxxLocalServiceUtil.createXxx(0) appel du constructeur du portlet Controller vers les méthodes correspondantes.

j'ai eu un problème similaire en faisant un maven portlet. D'abord j'ai fait le portlet et ensuite j'ai mis le service.xml

le problème était que le générateur cherchait un nom de portlet qui n'était pas là j'ai résolu de faire expliciter le nom de portlet j'ai voulu le génrator pour chercher

en particulier, pour ce faire, deux pom nœuds doit être égale à

projet.artifatctId = (liferay crée un localisateur de haricots pour cela)

et

projet.construire.(Liferay plugin).configuration.pluginName = le Nom interne du portlet pour le générateur

comme un exemple, un petit extrait de mon 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>

un et deux doivent être les mêmes

problème avec BeenLocator avec mon ressort portlet pour moi était que le contexte de ressort de mon portlet était initialisé avant le contexte de ressort de liferay.

j'ai été en utilisant ClassName className = ClassNameLocalServiceUtil.getClassName(JournalArticle.class.getName()); dans mon constructeur. Le contexte de LIferay n'était pas chargé, d'où l'erreur. J'ai déplacé ce morceau de code pour qu'il soit appelé quand (seulement ce temps) la première requête en avait besoin. Le problème a été résolu.

Donc, ne dépend pas de lifery lors de l'initialisation de votre portlet, faire une sorte de "paresseux" câblage de les dépendances de liferay.

puisque vous utilisez maven, essayez de vous assurer que votre nom de guerre est égal au nom de votre projet portlet. Après debug, j'ai trouvé que ClpSerializer définit _servletContextName est égal à <artifactId> du projet de guerre. Si vous déployez un artefact nommé artifactId-1.0.0-snapshot.war le contexte est créé avec ce nom, mais le code généré par le servicegen attend artifactId. Vérifiez avec votre ClpSerializer.

j'ai aussi eu le même problème. J'ai placé le code suivant dans liferay-plugin-paquet.fichier de propriétés de portlets qui utilise la couche de service de portlet commun. Il a travaillé pour moi.

required-deployment-contexts=common-portlet

il vaut mieux copier le service.le fichier jar à tomcat/lib/ext à la place de tous les portlets WEB-INF/lib.

N'a pas l'air de travailler pour l'exemple de Calendrier de portlet qui fait partie de la liferay Plugins 6.2 source.

erreur postée sur

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

j'ai fait ce qui suit pour résoudre le problème ci-dessus:

1. définir la propriété de configuration pluginName dans pom.xml pour le bon contexte

       <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. option définir le XXXX-portlet-déploiement-contexte de la propriété dans liferay plugin fichier de propriétés ou de portlet.fichier de propriétés

XXXX-portlet-deployment-context=XXXX-portlet

3. Re-Construire les services
4. vérifier si le ClpSerializer généré.java contient le bon contextes

' public static String getServletContextName() { si (Validateur.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. déployer la guerre, vérifier le nom de guerre et les journaux pour le nom de contexte correct.