Could not initialize class com.sun.star.lib.connections.pipe.PipeConnection

Bonjour,

Je reviens vous voir après une pause dans la publication de mes messages.

Je récapitule brièvement la situation :

  • j’ai installé une applet scenarichain-server 5 sur une Debian 10 à partir des paquetages… Sans problème
  • j’ai ensuite compilé une seconde applet toujours sur le même serveur : nickel et elles fonctionnent toutes les deux.
    Les deux applications sont sous le contrôle de Tomcat 9 et d’un reverse proxy nginx.

Le problème que je rencontre actuellement est ce message d’erreur java lorsqu’on essaie de publier un atelier au format opendocument compact :

Générateur: gen_paperLight - Support papier OpenDocument compact
Item racine: /_papier.publi
* Starting OpenDocument editor in pipe mode.
* Generation failed.
  - java.lang.NoClassDefFoundError: Could not initialize class com.sun.star.lib.connections.pipe.PipeConnection
    - Could not initialize class com.sun.star.lib.connections.pipe.PipeConnection

Si avec l’applet packagée, cela fonctionne parfaitement bien (génération sans message d’erreur), le problème apparaît avec l’applet compilée.

Avez-vous une idée d’où pourrait venir le problème ?
En vous remerciant d’avance pour votre aide
Cordialement
Philippe Vignoles

Une petite précision : le problème n’apparaît qu’avec la publication opendocument apparemment (les publications pdf semblent fonctionner correctement).

Cordialement
Philippe Vignoles

Bonjour,

Avez-vous bien installé libreOffice sur votre serveur Debian ?

Oui oui : libreoffice est bien installé et la génération fonctionne bien avec l’applet packagée installée.
C’est avec la 2e version du serveur (la version compilée) que la communication avec libreoffice ne semble pas se faire correctement.

Le chemin d’accès à LibreOffice est bien déclaré dans Scenari, pour que Scenari puisse le retrouver ?

Il s’agit de la version serveur de scenari. Libreoffice a été installé via les paquetages de Debian.
Si le chemin de Libreoffice n’était pas accessible au serveur scenari, est-ce que le problème ne devrait alors pas se produire pour les 2 services scenarichain-server (actuellement, un seul des deux services rencontre ce problème) ?

Bonjour @vignoles87,

De mémoire, ça n’était pas exactement ce message qui apparaissait, mais avez-vous mis en place ce paramétrage dans Tomcat pour mutualiser les libs LO entre plusieurs webapp ? https://doc.scenari.software/SCENARIchain-server@4.2/linux/fr/#tomcat_lin_1:Dr8QNqtLRRiXMHCtRcKFRd

cdt
Antoine
Kelis

Bonjour Antoine,

Merci pour votre réponse.

J’ai essayé de rajouter les chemins concernés dans la clause shared.loader mais en fin de compte, le problème s’est maintenant propagé à l’autre webapp. Du coup, avec cette configuration, je n’arrivais plus du tout à compiler en opendocument (même message d’erreur pour les 2 webapps)…
Apparemment, c’est bien un problème de chemin (enfin, c’est l’impression que ça donne).

Cordialement
PV

En fait, non ça ne doit pas être ça…
Maintenant, c’est l’inverse qui se produit : c’est l’applet qui rencontrait le problème de compilation qui marche et celle avec laquelle ça compilait qui ne compile plus…
Est-ce que cela pourrait venir d’un problème d’attribution de mémoire ?

Je ne pense pas, c’est un problème bas niveau entre du code natif de libreOffice (JNI) et la gestion du code java par Tomcat (ClassLoader). Dans votre cas c’est la 1ère app qui charge ces librairies « spéciales » (par un appel à une génération open-document) qui fonctionne, la suivante échoue.

Il faut que nous creusions pour comprendre pourquoi la procédure indiquée par @anp ne fonctionne apparemment plus.

Une autre solution serait d’utiliser un 2ème serveur d’application (Jetty…) pour votre 2ème app et isoler ainsi les process.

Oui apparemment, c’est bien cela : la première webapp qui utilise les ressources LO fonctionne et la seconde échoue. J’ai essayé après avoir arrêté et relancé tomcat mais je ne vois rien de spécial dans les log qui pourraient donner une piste intéressante.
Si la procédure proposée par Antoine ne fonctionne pas, est-ce que cela pourrait simplement provenir de la syntaxe : j’ai utilisé des chemins absolus vers les liens se trouvant dans le dossier /usr/lib/libroffice/program/classes ?

Vous utilisez bien LibreOffice6 ?

oui : la version proposée par Debian 10 soit la 6.1.5-3+deb10u6

Sylvain,
Je viens de faire pas mal de tests.

Tout d’abord : la bonne nouvelle est que la solution d’Antoine n’échoue pas totalement. Je me demande si j’avais renseigné la bonne clause (j’avais peut-être rajouté les chemins pour server.loader).
Mais cela ne résout pas pour autant ce problème de partage (même si je rajoute les chemins pour shared.loader. J’ai même tenté de généraliser avec le chemin « /usr/lib/libreoffice/program/classes/*.jar » mais sans plus de succès).

J’ai ensuite essayé de faire gérer les 2 applets par Jetty9… Pas mieux : même problème de partage.

J’ai essayé votre proposition en séparant la gestion : une applet pour tomcat et une applet pour jetty.
Cette configuration marche apparemment : on peut compiler en opendocument.

Bravo pour cette idée :wink:

Cela ne résout qu’en partie le problème car si j’ai besoin de rajouter une 3e applet, on retrouverait le même souci (à moins qu’on ne trouve un 3e serveur java ?)…

En l’état, ça va rester pour le moment. Je me repencherai sur ce problème plus tard en espérant que quelqu’un ait réussi à comprendre ce qui manquait dans la configuration de tomcat…

Merci pour votre aide à tous
Cordialement
Philippe Vignoles

Je suppose que quelque chose a changé avec la dernière version de Tomcat, il faut qu’on creuse car le multi-webapp doit pouvoir marcher.

Sinon nous avons aussi commencé à travailler sur une solution autonome, sans serveur d’application J2EE de type Tomcat ou Jetty (plus précisément, on « embed » Jetty). L’idée est de faciliter les déploiements et éviter ce type de problème… Mais il nous reste encore un peu de travail sur le sujet…

Bonjour, j’ai fait quelques tests :

Machine virtuelle de test : Debian 10 avec SCENARIsuite-starter5.0 et SCENARIchain-server5.0 installés en debs.

  • Si j’installe LibreOffice 6.1 de Debian en effet je n’arrive pas à faire marcher la paramétrage shared.loader dans /etc/tomcat9/catalina.properties.
    Les jars en question sont pas réellement dans /usr/lib/libreoffice/program/classes ou on trouve que des liens symboliques. J’ai testé avec les liens symboliques et avec leur emplaclement réel (/usr/share/java/) sans succès.
  • Si j’installe LibreOffice 6.4.7 deb, téléchargé depuis le site de LibreOffice.org avec le paramètre shared.loader=/opt/libreoffice6.4/program/classes/jurt.jar,/opt/libreoffice6.4/program/classes/ridl.jar,/opt/libreoffice6.4/program/classes/unoil.jar alors ça marche parfaitement.

Conclusion : si on veux faire marcher plusieurs webapps SCENARI utilisant LibreOffice dans le même moteur de servlets il faut utiliser la version « officielle » de LibreOffice et pas la version packagé par Debian, ou alors il faut faire plus investigations.

Bonjour Sam,
Merci pour ces informations et d’avoir fait ces tests.

C’est rare qu’un package de Debian soit « bridé » ou dysfonctionne… Comme quoi tout arrive.
J’avais hésité à installer une version un poil plus récente depuis le site.

En tout cas, cela est rassurant : le problème vient bien des librairies LO et il ne s’agit pas d’un problème de configuration de Tomcat.

Cordialement
Philippe Vignoles