Domino 11.0.1: Externe JAR einbinden und verwenden (Linux)

[Tode]

Ich habe unter 9.0.1 eine "Datenpumpe" geschrieben, die mittels JDBC Daten aus / in relationale Datenbanken pumpt, quasi "IEI für Arme".
Damit das auf dem Server sauber funktioniert, habe ich den JDBC- Treiber unter /opt/hcl/domino/notes/latest/linux/jvm/lib/ext

abgelegt. In der Java Scriptlibrary lade ich dann die Class:

Code

Class.forName(m_strjClassName);
		// Connect to the database
				
		if (m_strjUserName != "") {
			m_lcConProp.put("user", m_strjUserName);
			m_lcConProp.put("password", m_strjPassword);
		}
		m_lcCon = DriverManager.getConnection(m_strjUrl,m_lcConProp);

Das hat unter 9.0.1 wunderbar funktioniert (ohne Anpassung java.policy / java.pol), aber seit dem Update auf 11.0.1 lädt er die Klasse nicht mehr.

24.02.2021 06:00:08 AMgr: Agent ('java.JDBC_Periodical' in 'apps/DataPump.nsf') error message: Exception in thread "AgentThread: JavaAgent"
24.02.2021 06:00:08 AMgr: Agent ('java.JDBC_Periodical' in 'apps/DataPump.nsf') error message: java.lang.NoClassDefFoundError: com.mysql.cj.jdbc.Driver (initialization failure)

Ich verwende den aktuellsten mySQL- Treiber, der explizit für Java 8 ist (mit Domino 11 wurde ja auf openjvm 1.8 umgestellt). Die Linux- Berechtigungen auf "mysql-connector-java-8.0.23.jar" sind identisch zu denen der anderen jars aus dem Verzeichnis.

Ich meinte irgendwo was gelesen zu haben, dass externe jars in Agenten Probleme machen seit Domino 10 oder 11, kann aber ums Verrecken den/die Artikel nicht mehr finden.

Irgendwelche Tipps für mich?

[jBubbleBoy]

Bei einem Domino 11.0.1FP2 und für Oracle ist das genau so im Einsatz.

Der Oracle-Treiber als Archiv im Agenten gingt nicht, das erzeugte Java-Fehlermeldungen, sollte man in diesen Fall aber ausprobieren. Und es gibt noch die Möglichkeit über die notes.ini und JavaUserClasses Java-Archive bekannt zu machen.

[maxritti]

Ich meinte irgendwo was gelesen zu haben, dass externe jars in Agenten Probleme machen seit Domino 10 oder 11, kann aber ums Verrecken den/die Artikel nicht mehr finden.

Hilft Dir nicht wirklich, aber zumindest unter Domino 10 habe ich solch ein Konstrukt zu einem MS SQL Server laufen.
Die jar Datei einfach in das von dir angegeben Verzeichnis und gut ist. 

[Ralf_B]

Ich habe die selbe Erfahrung wie Erik,
die Libs im Agenten machen Probleme. Im lib/ext Ordner geht es.
Ich nutze SAP JCO/und andere ...   und musste auf Win/AIX die Java Security anpassen, weil die Lib's sonst nicht geladen wurden.
Allerdings nur Domino 9/10 und nicht 11.

[eknori]

Ist das überhaupt die richtige Basisklasse? Ich verwende die ...20 in einem OSGi plugin. In V ..22 funktioniert das auch noch. V ..23 habe ich noch nicht reingeschaut. Grundsätzlich verwende ich den gleichen Aufruf, wie Du.
Werden andere .jardenn aus dem Verzeichnis ohne Fehler geladen?

Was die libs in Agenten angeht, dazugibt es einen SPR von mir. Die libs werden bei jedem Aufruf neu geladen und führen irgendwann zu einem Speicherüberlauf.
Das soll gefixt werden, ist aber ein größeres Rad, an dem gedreht werden muss.
Ob ich das in meinem Leben noch erlebe, wage ich zu bezweifeln.

[Tode]

Hi zusammen, danke für die Hilfe bisher. Ich habe nur diese eine jar im Verzeichnis, deshalb weiss ich nicht, ob andere geladen werden. Vor dem update des Servers von 9.0.1FP9 auf 11.0.1 FP2 war im selben Verzeichnis (nur IBM statt HCL) eine ältere Version der Library und das ist schon ewig gelaufen. Nach dem Update ging es nicht mehr, da habe ich versucht, ob es an der Version der Lib liegt und die neuste reingepackt. Eine Änderung an der java.pol bzw. Java.policy war nicht notwendig (unter 11 gibt es ja eh nur noch eine der beiden)...

Ach ja: die anderen jars in dem Verzeichnis sind nich custom, das sind die default dateien, die da immer liegen...

Bin etwas ratlos...

[jBubbleBoy]

Der Fehler "java.lang.NoClassDefFoundError: com.mysql.cj.jdbc.Driver" besagt das er die Java-Klasse nicht findet, das bedeutet er findet die bereitgestellte Jar-Datei nicht.

[eknori]

Packe die .jar mal ins ndext Verzeichnis. Ich vermute, dass dein jvm/lib/ext nicht im classpath ist.

[Tode]

Ich dachte, der wäre automatisch immer drin. Ich werde das am Donnerstag mal probieren (vorher komme ich nicht in die Umgebung). Danke für die Hinweise. Ansonsten werde ich mir mit der INI- Variable JavaUserClasses zu helfen versuchen.

[Tode]

OK. Jar ist jetzt im ndext. Jetzt bekomme ich tatsächlich eine andere Meldung:

java.security.AccessControlException: Access denied ("java.lang.RuntimePermission" "setContextClassLoader")

Ich habe die java.policy geprüft, da steht folgender Eintrag:

Code

grant codeBase "file:${notes.binary}/ndext/*" {
        permission java.security.AllPermission;
};

Aber "AllPermission" ist hier wohl irreführend. Ich habe es mal so ergänzt:

Code

grant codeBase "file:${notes.binary}/ndext/*" {
        permission java.security.AllPermission;
        permission java.lang.RuntimePermission "setContextClassLoader";
};

Da immer noch die gleiche Meldung kommt, fürchte ich jetzt nur, dass ich den Domino Server für das Einlesen der neuen policy durchstarten muss, denn das durchstarten des AMGR hat keine Änderung gebracht, und in einer Anleitung zu Domino Volt steht, dass man nach Änderung der java.policy den Domino durchstarten soll...

EDIT: Grade geprüft... wenn man in der "alten" Errormessage weiter runterscrollt, dann war schon dort die selbe Ursache "AccessControlException" drin... man sollte einfach die Fehler zu Ende lesen und nicht bei dem ersten Hinweis losrennen... also ist wohl auch in Domino 11 jvm/lib/ext immer noch im Standardpfad, und die Ursache ist eine Änderung in der Policy (oder ich hatte damals beim Einrichten tatsächlich eine java.pol gepflegt und das nicht dokumentiert)

[Ralf_B]

Wir hatten bislang bei einem Domino 11 Server den Fall, dass wir zusätzlich zu AllPermission auch das Laden explizit ergänzen mussten.
Warum auch immer.

Edit: Ich hab in meiner Doku auch den Punkt des Neustarts des Servers nach der Policy Änderung.

[Tode]

OK. dann warte ich mal den Neustart ab und schaue, ob das dann funktioniert. Danke für die Rückmeldung

[eknori]

FYI:
Ich bin gerade mit Domino 12 (Windows) auf das gleiche Problem gestossen.
Ohne eine Änderung der java.policy habe ich es auch nicht hinbekommen.

Was ich sehr verwirrend finde it, das HCL bitidentisch den code auch im Traveler verwendet, und der kann den selben Treiber im selben Pfad problemlos laden. Nur mein OSGi plugin nicht.


Und hier noch eine Info, die ich in einem anderen Forum gefunden habe https://bugs.mysql.com/bug.php?id=88172
Sieht so aus, als ob der Treiber das Problem ist, und der intern ein flag setzt, was dann zu dem security issue führt. Also nicht einmal der ausführende Java code.
  

[eknori]

Es hat wohl eine Änderung gegeben, wie die JVM in den einzelnen Diensten initialisiert wird. Das betrifft nicht nur den Amgr, sondern auch HTTP und DOTS.ab welcher Version? Keine Ahnung.
Die Änderung ist generell kein Problem. Das eigentliche Problem ist das, was in dem o.a. Link zum mysql Treiber beschrieben ist. 
Vor der Änderung war das Problem kein Problem.

Mit anderen Treibern sollte der Code zum dynamiachen Laden eines Treiber auch weiterhin funktionieren.

Ich trage das mal weiter zusammen. Ein sehr spezielles Problem, das evtl. Nur 2 Leute interessiert. Aber egal.

[eknori]

Ich habe da mal was aufgeschrieben
https://www.eknori.de/2021-06-04/load-jdbc-sql-driver-at-runtime-in-dots-and-amgr/

[Tode]

Vielen Dank für Das Zusammenschreiben. Das schaue ich mir auf jeden Fall genau an.