Domino 9 und frühere Versionen > ND6: Entwicklung

While Schleife auf Server wird nicht ausgeführt

<< < (4/5) > >>

koehlerbv:
An den Autorenfeldern lag es aber nicht, Tom. Dann hättest Du innerhalb der Schleife eine andere Fehlermeldung bekommen, wenn Du versucht hättest, ein Dokument zu speichern. Es waren - genau wie Axel gesagt hat - die Leserfelder.

Bernhard

Marinero Atlántico:
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:

--- Zitat ---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

--- Ende Zitat ---

* 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

umi:
Oder man verwendet das OpenLog von www.openntf.org, da hats ein sehr schönes Log inkl. LS und JAVA klassen fürs logging und debugging.

Marinero Atlántico:
@Umi: Was sind die konkreten Vorteile des Logging von diesen open sores gegenüber des bereits in Notes vorhandenen???
Oder wollen die vielleicht nur auch mal ein me-to Logging erstellen und ein bischen rumprangern ???

umi:
@Marinero
Dazu kann ich nicht viel sagen, da ich die NotesLog Umgebung nicht gut genug kenne.

+Das Openlog bietet schon eine einfache Klasse an, die mir die meisten Log fragen löst. Einfach einzubinden (scriptlib) einfach aufzurufen (call logerror)

+Ausserdem bietet es die Möglichkeit Alarme zu definieren auf das Logfile 'Wenn Fehler XYZ dann Meldung an bla@bluh"

+sieht besser aus als das noteslog :-)

+Loggt mit einem aufruf folgende infos:
Event type
Event time
Error number
Error line number
Error message
Agent/script language
Server name
Database name
Agent name
User Name
Effective User Name
User ACL access and roles for the current database
Client version in use on the workstation or server
Erroring function/sub/method name
Error stack trace (for all Java agents and LotusScript agents running on a release 6 or higher server)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete