JVM wechselt Verzeichnis

[pram]

Hallo zusammen,

wir haben bei einem Kunden ein Problem mit der notes-eigenen JVM. Hier soll ein JAR File per Shell Befehl ausgeführt werden. Allerdings scheitern schon Versuche, diesen Befehl an der Konsole korrekt abzusetzten.

Das Kundensystem ist ein
Lotus Domino (r) Server (Release 8.5.3FP6 for UNIX) 23.09.2014 16:19:03
Red Hat Enterprise Linux Server release 5.10 (Tikanga)
(Der Kunde ist eine Bank und ich kann aktuell nicht sagen, in wie weit das System von einer Standardinstallation abweicht)

Das JAR-File, sowie einige Zusatzdateien wurden unter "/export/home/notesuser/notesdat/applikationen/testapp/" abgelegt. Die Notes-VM befindet sich unter "/opt/ibm/notes/lotus/bin/java"

Gebe ich nun an der Kommandozeile folgendes ein:

Code

cd /export/home/notesuser/notesdat/applikationen/testapp/
/opt/ibm/notes/lotus/bin/java -jar ./testjar.jar

ein, so bekomme ich einen "Unable to access jarfile ./testjar.jar" Fehler.

Die Rechte und alles passen. Ich bin auch definitiv im richtigen Verzeichnis, da ich mit "ls" die JAR-Datei sehe.
Gebe ich nämlich den vollen Pfad an

Code

/opt/ibm/notes/lotus/bin/java -jar /export/home/notesuser/notesdat/applikationen/testapp/testjar.jar

so wird die JAR-Datei ausgeführt. Die JAR benötigt aber noch zusätzliche Dateien/Verzeichnisse, welche im aktuellen Verzeichnis liegen sollten (was /export/home/notesuser/notesdat/applikationen/testapp sein sollte, da ich zuvor dahin gewechselt habe)

Leider wechselt die JVM aber aus mir unerklärlichen Gründen in das Notes-Daten Verzeichnis "/export/home/notesuser/notesdat". Dies lässt sich aus den Fehlermeldungen ableiten, die die JAR Datei bringt.

Die Notes.ini habe ich schon geprüft, hier steht "Directory=/export/home/notesuser/notesdat", was aber normal ist.
Bei den anderen Parametern ist auch nichts verdächtiges dabei.
In den Umgebungsvariablen finde ich den Pfad in $HOME und $NOTESDATA_DIR, was aber auch nicht stören sollte.

Fakt ist, dass bei diesem Kunden die JVM nicht mit relativen Pfaden umgehen kann.
Bei allen mir sonst zur Verfügung stehenden Testsystemen führt nämlich ein Aufruf der Form

Code

/opt/ibm/notes/lotus/bin/java -jar ./testjar.jar

die JAR Datei im aktuellen Verzeichnis aus (und sucht diese nicht im Notes-Daten-Verzeichnis. Dies habe ich aber noch nicht gesichert verifiziert - werde noch probieren, was passiert, wenn ich die JAR ins Datenverzeichnis lege, ob dann ein "java ./testjar.jar" immer auf diese zurückgreift, egal in welchem Verzeichnis ich bin).

Aktuell fehlen mir weitere Ansätze.

Gruß
Roland

[umi]

Moin

Evtl explizit noch den Classpath zu den weiteren Jar's angeben beim Aufruf ?

[flaite]

bin mir nicht sicher, aber check mal ob auf dem sich-anders-verhaltenden Rechner die Umgebungsvariable JAVA_HOME gesetzt ist, auf den anderen aber nicht.

[pram]

Die Variablen haben eigentlich gepasst, wir haben auch versucht, alle Pfade absolut anzugeben, es gibt aber (leider) Codestellen, die auf das aktuelle Verzeichnis referenzieren, da im Dateisystem Dateien gelesen/geschrieben werden.
Deshalb brachte uns eine Angabe von absoluten Pfaden hier nicht weiter...

Gemeinsam mit dem Kunden haben wir aber inzwischen heraus gefunden, an was es lag:

Das Problem war, dass die falsche "java" executable verwendet wurde.

Auf unseren Testsystemen verwendeten wir diese

Code

/opt/ibm/lotus/notes/latest/linux/java

welche ein Symlink auf

Code

/opt/ibm/lotus/notes/latest/linux/jvm/bin/java

ist (und dies ist das ELF-Binary)

Beim Kunden wurde eine andere verwendet, diese befindet sich auch auf meinem Testsystem hier:

Code

/opt/ibm/lotus/bin/java

welche über mehrere Symlinks schließlich auf

Code

/opt/ibm/lotus/notes/latest/linux/startup

verweist, welches ein komplexes WrapperScript für java u.a. ist. Hier wird wohl irgendwo der Pfad verbogen

Da beim Kunden die Pfade etwas anders sind als auf meinem Testsystem, ist mir der Fehler nicht sofort aufgefallen, dass das falsche "Binary" verwendet wurde. (Beim Kunden wurde nicht in "/opt/ibm/lotus" installiert.)

Meinen letzten Post muss ich nach dieser Erkenntnis auch korrigieren:
Der Aufruf von

Code

/opt/ibm/lotus/bin/java -jar ./testjar.jar

funktioniert auch auf dem Testsystem nicht, (es wird dann auch der Wrapper gestartet, welcher identisches Verhalten wie beim Kunden zeigt)
Der Aufruf von

Code

/opt/ibm/lotus/notes/latest/linux/jvm/bin/java -jar ./testjar.jar

klappt aber. (Beim Kunden liegt dieses Binary in einem anderen Pfad und der Aufruf klappt nun auch)

Danke nochmal für alle die mir Tipps gegeben haben, vielleicht tappt mal wer in die gleiche "Falle".
Wer ahnt schon, dass im Installationsverzeichnis 2 "java" executables liefern, die unterschiedliche Funktionen haben  

Gruß
Roland