Trotzdem ist es aus meiner Sicht sehr sinnvoll, dass man sich für serverseitige Agenten ein auf NotesLog bestehendes Framework schafft.
Man braucht sich auch selbst keine eigene Logging Infrastruktur (eigene LogView, LogDokumente etc.) zu schaffen, weil mit dem aLog4.ntf in den erweiterten Schablonen schon alles vorhanden ist.
Dieses kann man dann prima mit der Klasse NotesLog ansprechen.
Um den Zugriff noch einfacher zu machen kann man sich ein eigenes Framework in Form von Klassen oder Scriptlibraries zu schaffen.
Das mit den print-Statements ist nicht so gut, weil die Einträge in der Log.nsf etwas später sichtbar sind gegenüber der Erzeugung und man nicht immer Zugriff auf die Life-Konsole hat, die überdies ziemlich ressourcenhungrig ist.
Ein wichtigeres Problem von log.nsf ist, dass da auf Produktivservern oft einfach viel zu viel drinsteht. U.a. weil Entwickler vergessen ihre debug-print statements da rauszunehmen, was wiederum die Administratoren verärgert.
Ich habe auch einen Kunden, wo ich garnicht in die Log.nsf auf Produktivservern sehen darf. Aus Sicherheitsgründen.
Gerade für serverseitige Agenten, gibt es mit NotesLog Möglichkeiten, die ich noch nicht ausprobiert habe aber bei Log4J in Java genauso laufen. Man kann das Logging zwischendurch ausschalten und es im Problemfall mit einer minimalen Code bzw. Config-Dok Änderung wieder einschalten (s. Methode LogEvent) zum Tracen.
Warum zwischendurch ausschalten? Bessere Performance.
Es geht hier um nicht-funktionale Requirements. Also Dinge, die der User nicht direkt als Feature bemerkt, die aber insgesamt die Total Costs of Ownership der gesamten Notes-Umgebung senken, weil z.B. hier eben Fehler leichter zu tracen sind.
Notes bietet hier seit R4 eine standardisierte, sinnvolle und gut-durchdachte Lösung. Oder gibt es da irgendwelche Gegenmeinungen
Diese wird imho nicht ausreichend genutzt. Natürlich kann man sein eigenes unperformanteres und schlechteres Logging Framework schreiben. Dann braucht man das Notes-Standard-Logging nicht zu lernen. Der nächste Entwickler muss dann aber wieder dein Logging verstehen.
Oder wie der großartige Java-Satiriker Hani Suleiman nicht müde wird zu sagen:
So please, please, stop hurting us poor users*. There's enough other stuff that defecates on us from great enough heights that this last touch seems just a bit excessive
* wenn ich eine bestehende Anwendung "repariere" bin ich erstmal ein User dieser Anwendung, weil ich den most brilliant code der Vorgänger erstmal verstehen muss.
Gruß Axel
