Moin Moin,
ich habe mir mit Eclipse ein Jar gebaut, welches ein einfaches BAPI (BAPI_COMPANYCODE_GETLIST) aufruft.
Wenn ich das Jar in einen Agenten einbinde, läuft der Agent genau ein mal. Beim zweiten Aufruf kommt die Fehlermeldunug: java.lang.NoClassDefFoundError: com/sap/mw/jco/JCO
Ich bräuchte einen Schubs in die richtige Richtung ...
Danke,
SD
Naja, laut Knowldegebase scheint das beim Webshpere wohl ständig, überall und alle Nase lang aufzutreten. Anyway, beim Domino7 hab ich nur ein halbwegs logischen Eintrag gefunden. Demzufolge allerdings sollte dein Agent auch beim ersten Mal schon Fehler spucken, vielleicht hab ich ja trotzdem getroffen.
Keine Ahnung, von Java weiß ich nur 3 Dinge:
1) es gibt sowas,
2) ist eigentlich ein Kaffe,
3) mehr will ich nicht wissen :nono:
Das war doch schon der Stups in die richtige Richtung ... :idea:
Ich hatte das 'sapjco.jar' in den Agenten eingebunden. Nachdem ich die 'sapjco.jar' nach '[...]notes\jvm\lib\ext\' kopiert habe läuft er jetzt.
Keine Ahnung ob es der richtige Weg ist ... das nächste Problem wird das Ausrollen sein.
Prüf mal ob der Agent beim ersten mal abgestürzt oder mit Fehler ausgestiegen ist.
Ich hatte mal ein ähnliches Problem und da lag es daran, daß bei einem unsauberen Beenden des Java Agenten beim nächsten Start die eingebundene Jar nicht mehr geladen werden konnte.
Als ich alle Fehler abgefangen hatte und für ein sauberes Ende gesorgt habe ging es problemlos.
Das reinkopieren in das genannte Verzeichnis ist zwar eine Möglichkeit allerdings musst du dann auch bei jedem Update dieser Jar Datei das nachholen und problematisch wird es vor allem wenn du mehrere Agenten mit unterschiedlichen Versionen der Jar hast
Zitat
taurec schrieb:
Prüf mal ob der Agent beim ersten mal abgestürzt oder mit Fehler ausgestiegen ist.
Der Agent läuft beim ersten Starten bis zum Ende durch. Ist es leider auch nicht.
Zitat
Das reinkopieren in das genannte Verzeichnis ist zwar eine Möglichkeit allerdings musst du dann auch bei jedem Update dieser Jar Datei das nachholen und problematisch wird es vor allem wenn du mehrere Agenten mit unterschiedlichen Versionen der Jar hast
Kann man nur hoffen, das SAP das JAR abwärtskompatibel hält ...
Thx,
SD
Fängt er Fehler durch ein try except ohne Ausgabe einer Fehlemeldung ab ?
Hier mal der Agent ...
package com.test.jco;
import lotus.domino.*;
public class JavaAgent extends AgentBase {
public void NotesMain() {
try {
Session session = getSession();
AgentContext agentContext = session.getAgentContext();
try {
System.out.println("start");
JCOConnect app = new JCOConnect();
app.bapi_companycode_getlist();
} catch (Exception e) {
System.out.println("catch 1");
e.printStackTrace();
}
} catch(Exception e) {
System.out.println("catch 2");
e.printStackTrace();
}
System.out.println("AGENT DONE");
}
}- Die Meldung "AGENT DONE" kommt beim ersten Durchlauf in der Java-Konsole
Wenn ich mich im [d]Notes.net[/d] ldd so umsehe, ist das kopieren der Dateien in /jvm/lib/ext der richtige Weg. Offizielle Doku habe ich dazu noch nicht gefunden.
Und wo gibst du das JCO Objekt wieder frei ?
Bei den meisten externen Objekten sollte dieses explizit wieder freigegeben werden und zwar sowohl bei regulärer wie auch im Fehlerfalle.
Das kann ich hier nirgendwo sehen.
Genau das war damals auch die Ursache.
Zitat
taurec schrieb:
Und wo gibst du das JCO Objekt wieder frei ?
JCOConnect ist eine von mir geschriebene Klasse, die sich Verbindungen aus dem "connection pool" holt und nach Beendigung diese wieder an den Pool zurückgibt.
Vom Agentmanager/VM erwarte ich, das JCOConnect nach Beendigung weggeräumt wird.
Laut SAP Doku gilt der Pool gilt für die gesamte VM (ohne Pool würde es auf demServer nicht laufen).
Gibt es unterschiede bei der IBM-VM in Domino/Notes?
Schön dass du das erwartest.
Das größte Problem bei solchen Klassen die externe Systeme ansprechen ist eben, daß diese Freigabe nicht immer völlig passiert.
Das gleiche Problem hast du auch wenn du mit den Notes Java Klassen arbeitest.
Prinzipiell sollte in jeder Art von Programm immer aufgeräumt werden und sich nie auf einen Automatismus verlassen werden.
Das ist unabhängig von der Programmiersprache.
Also ruf in deiner eigenen Klasse auch explizit die Destruktoren der Verbindungsklasse auf.
Zitat
taurec schrieb:
Schön dass du das erwartest.
Das suggeriert zumindestens die Java-Dokumentation
Zitat
Also ruf in deiner eigenen Klasse auch explizit die Destruktoren der Verbindungsklasse auf.
Die da wären? Das ist Java und kein C++. 'finalize' ist protected und für den GC da.
Das einzige was ich in der JCO Dokumentation gefunden habe ist, das man immer die Verbindung an den Pool zurückgeben muss. Destuktoren sind mir in Java gänzlich unbekannt.
Destruktoren sind auch nichts anderes wie Methoden die aufgerufen werden und das Aufräumen übernehmen.
In jeder mir bekannten Sprache die Klassen unterstützt sollte ein Destruktor (egal ob manuell oder automatisch) aufgerufen werden.
denn die automatischen Aufräummechanismen sind zwar schön und gut können aber nie alle Eventualitäten abdecken.
Und gibst du denn in deiner Klasse die Verbindung an den Pool zurück ?
Zitat
taurec schrieb:
In jeder mir bekannten Sprache die Klassen unterstützt sollte ein Destruktor (egal ob manuell oder automatisch) aufgerufen werden.
denn die automatischen Aufräummechanismen sind zwar schön und gut können aber nie alle Eventualitäten abdecken.
Herr Lehrer, ich weiß was! :lol:
Nee, ernsthaft, ich hab zwar gesagt, dass ich von Java nix weiß und nix wissen will, kommt aber daher, dass ich mich eine zeitlang damit beschäftigen musste, aber nicht warm damit geworden bin. Ok, worauf ich hinaus will ist, dass Java keine Destruktoren hat, sondern den GC. Allerdings sagt die SUN-eigene Java-Doku
Zitat
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
So wie ich das damals verstanden habe, läuft es so, dass man den GC aufrufen kann, oder auch nicht, es nimmt sich nix. Zum Einen räumt der GC von sich aus von Zeit zu Zeit auf. Zum Anderen hat ein expliziter Call vom GC nichts weiter zur Folge, als dass man den GC höflich drum bittet, eventuell, wenn er nix besseres zu tun hat, einen Versuch zu unternehmen, aufzuräumen. Ob er das tut, oder nicht, kann nicht wirklich überprüft werden. Er sagt immer nur, dass er "sein möglichstes" getan hat. Was auch immer das bedeutet...
Destruktor ist ja eigentlich nur eine Definition. In manchen Sprachen ist dieser explizit umgesetzt, in anderen muss man sich eben selber drum kümmern. Java gehört eben zum letzten.
Was ich aber auch bei der Java Programmierung gelernt habe, ist das eine Freigabe von Verbindungen und Objekten möglichst immer selbst gemacht werden soll, denn so wie RockWilder den Text aus der Java Doku verstanden hat ist es leider auch.
Der GC kümmert sich vielleicht wenn er mal Zeit hat drum aufzuräumen.Tut er das nicht oder nicht rechtzeitig genug, dann können eben solche Effekte zustande kommen, wie daß er Klassen auf einmal nicht mehr findet.