Eigenes JSR-168 Portlet und Restart des Tomcat-Servers

[Thomas Fröhlich, geändert vor 14 Jahren.]

Hallo und guten Tag,

ich verwende LIFERAY in der folgenden Konstellation:

- Tomcat 6.0.20 Installation mit getrennetn CATALINA_HOME -
und CATALINA_BASE - Verzeichnissen (best practice)
- Installation von LIFERAY 5.2.3 (liferay-portal-5.2.3.war) als ROOT-Applikation

LIFERAY funktioniert tatellos (inkl. LDAP und CAS). Nun habe ich unter Verwendung des LIFERAY SDK ein eigenes simples JSR-168 konformes Portlet "geschrieben" (intalioUI-portlet).

Das Portlet läßt sich in den gestarteten LIFERAY-Portal-Server problemlos deployen: egal, ob per HotDeploy oder über das Control Panel im LIFERAY. Liferay/Tomcat entpackt das WAR-File im WEBAPPS-Folder parallel zum LIFERAY-ROOT-Folder. Nach dem Deployment steht mir das Portlet unter "Add Application" zur Verfügung. Alles kein Thema und alles bestens.

Ein Problem habe ich nach dem Neustart des Tomcats. im log-File habe ich dann folgende Exception:

com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering portlets for intalioUI-portlet

Folge dieser Exception ist, dass das Portlet unter "Add Application" nicht mehr zur Verfügung steht. Außerdem scheint der Plugin-Manager im Control Panel total durcheinander zu kommen - keines der Core Plugins wird mehr angezeigt.

Durch reinen Zufall habe ich das Tomcat-TEMP - Verzeichnis überwacht und beim Neustart gesehen, das dort zuerst ein neues TEMP-Verzeichnis für das Portlet und erst danach für Liferay angelegt wird. Ursache meines Problems ist also mit ziemlicher Sicherheit die parallele Threat-basierte Startreihenfolge der beiden Applikationen durch Tomcat. Tomcat kennt hier keine Abhängigkeiten und Startreihenfolge und das schlankere Portlet wird schneller gestartet als LIFERAY....

Was kann ich hier tun, dass auch nach einem Server-Neustart das Portlet im LIFERAY zur Verfügung steht?

Vielen Dank
Thomas

[Thomas Weckert, geändert vor 14 Jahren.]

Hallo Thomas,

man soll zwar niemals nie sagen, und bei Liferay ist ziemlich viel möglich, aber trotzdem kann ich mir nicht so richtig vorstellen daß Deine Schilderung der Grund des Problems ist.

Wenn der Code des Portlets an und für sich "korrekt" und fehlerfrei ist, es sich aber nicht vernünftig deployen lässt, dann lag es bei mir fast immer daran daß ich einen Fehler in der Liferay spezifischen Konfiguration (liferay-plugin-package.xml, liferay-display.xml etc.) des Portlets hatte. Ich hatte vor kurzem dadurch auch Probleme mit dem Deployer, vielleicht hilft Dir das weiter.

Gruss, Thomas

[Thomas Fröhlich, geändert vor 14 Jahren.]

Hallo Thomas,

man soll zwar niemals nie sagen, und bei Liferay ist ziemlich viel möglich, aber trotzdem kann ich mir nicht so richtig vorstellen daß Deine Schilderung der Grund des Problems ist.

Du hast vollkommen Recht - es sah nach den ersten Tests eben scheinbar nur so aus, als würde die Startreihenfolge bzw. die Nebenläufigkeit der Threads eine Rolle spielen.
Ein Test hat gezeigt, dass es daran nicht liegen kann: Wir haben ein "fremdes" Portlet und ein simples eigenes (mit dem LIFERAY SDK gebautes) "Hello World" - Portlet testweise installiert.
Auch nach einem Neustart des Servers gab es keinerlei Probleme mit den Portlets - und erst recht keine com.liferay.portal.kernel.deploy.hot.HotDeployException mehr.

Also musste es, wie Du es zu Recht vermutet hast, an einer der Portlet - Konfigurationsdateien liferay-display.xml, liferay-plugin-package.xml, liferay-portlet.xml oder portlet.xml liegen.
Diese haben aber alle "gepaßt". Mehr durch Probieren haben wir herausgefunden, dass folgende Einträge in der web.xml des Portlets (!) an der Exception Schuld haben:

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<context-param>
  <param-name>contextClass</param-name>
  <param-value>org.intalio.tempo.web.SysPropWebApplicationContext</param-value>
</context-param>

<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>file:${org.intalio.tempo.configDirectory}/tempo-ui-fw.xml</param-value>
</context-param>

Vielleicht zum Hintergrund: Wir versuchen ein "älteres" Portlet, von dem wir die Sourcen haben, zu aktualisieren und mit neuen Bibliotheken und Klassen neu zu bauen, so dass es im LIFERAY 5.2.3 wieder "funktioniert". Wir wollten uns eigentlich nicht in den Inhalt der nicht unerheblichen Quelltexte einarbeiten (deshalb kann ich auch nicht wirklich stichhaltig erklären, warum das Entfernen der obigen XML-Nodes "geholfen" hat bzw. welche weiteren Probleme wir dadurch bekommen werden...). Leider ist es eben doch nicht so einfach, wie erhofft.

Grüße
Thomas

[Thomas Weckert, geändert vor 14 Jahren.]

Hallo Thomas,

Thomas Fröhlich:

Du hast vollkommen Recht - es sah nach den ersten Tests eben scheinbar nur so aus, als würde die Startreihenfolge bzw. die Nebenläufigkeit der Threads eine Rolle spielen.

Danke

Nun aber zu Deinem Posting. Ich verstehe nicht, welcher Eintrag in der web.xml Deiner Meinung nach "böse" sein soll. Der Spring "ContextLoaderListener" hat bei mir noch nicht Probleme verursacht.

Aber was ist "SysPropWebApplicationContext"? Googelt man danach findet man: "Custom XMLWebApplicationContext that allows loading configuration files using system properties". Hört sich schon mal verdächtig an, hier könnte etwas kollidieren. Üblicherweise denken ja alle Web Frameworks "sie wären alleine" in der Applikation und können tun und lassen was sie möchten. Das Problem ist daß das Liferay API das natürlich auch denkt.

Hoffe ich konnte trotzdem etwas helfen.

Gruss, Thomas