Open gdi-by opened 7 years ago
Ich nehme an, dass "Alle Requests" bedeutet:
und deren Ergebnis (OK, Nicht OK).
Welche Detailstufe soll die Ergebnismeldung haben? Reichen HTTP-Statuscodes, oder sollen HTTP-Statuscodes in sprechende Fehlermeldungen aufgelöst werden?
Sind Zeitstempel benötigt?
Wo soll das Log im Dateisystem liegen?
Die Antworten dazu unter #GDI: Ich nehme an, dass "Alle Requests" bedeutet:
Anfragen an den WMS
Anfragen an den CSW
Anfragen an den WFS
Anfragen an den ATOM-Dienst
#GDI: Ja
und deren Ergebnis (OK, Nicht OK). Welche Detailstufe soll die Ergebnismeldung haben? Reichen HTTP-Statuscodes, oder sollen HTTP-Statuscodes in sprechende Fehlermeldungen aufgelöst werden? #GDI: http-Statuscodes, z.B. "401 Unauthorized". Ziel ist hier, den Errorgrund dokumentiert zu haben. Nur "Nicht OK" ist dann nicht ausreichend.
Sind Zeitstempel benötigt?
#GDI: Ja
Wo soll das Log im Dateisystem liegen?
#GDI: {Temp-Ordner-des-Systems}/downloadclient
Noch ergänzende Informationen:
Anwendungslog: Realisierung über LOG4J
Log sollte konfigurierbar sein (log4j.properties im conf Ordner). • max. Größe 10 MB • Name: logdlc_yyyymmddxx.... (x= beliebige aber benötigte Zahlenanzahl) • Loglevel ändern (Default „info“). debug -> info -> error
Loggingschritte
• INFO: Start des DownloadClients und verwendete Settings der Configfiles (Dump des Configcontainters). Hinweis Proxy-Settings müssen ersichtlich sein. • DEBUG: WMS-Requests des Clients • INFO: Alle HTTP(s)-Requests (Ausnahme WMS) und deren Methode (Head, Get, Post) und deren Response Status • DEBUG: Alle HTTP(s)-Responses (Ausnahme WMS) • INFO: Dump (toString()) der internen MetadatenContainer „WFSMeta“ bzw Atom. • ERROR: Generell: Exceptions mit Stacktraces • INFO: Alle aufgerufenen Kommandozeilenprogramme inklusive Aufruf • INFO: Aufruf der Hilfe (URL) • INFO: Informationen über das Laden und Speichern von Konfigurationen • INFO: Beenden des DownloadClients
Beauftragt - Umsetzung zum 11.07.2017
Implementationsvorschlag:
Wir haben 3 verschiedene Logs identifziert. Zum einen den Status-Log, der in der untersten Zeile der Oberfläche zu sehen ist. Zum anderen der Download-Log, welcher zur Zeit direkt bei den heruntergeladenen Daten liegt und zuletzt den Applikations-Log, welcher Requests zu externen Diensten und einige allgemeine Applikationsinformationen speichert.
Die momentane serviceSetting.xml (https://github.com/gdi-by/downloadclient/blob/master/src/resources/serviceSetting.xml) wird umbenannt in setting(s).xml und sie wird um den Punkt "Log" erweitert. Beispielhaft werden die Einträge dort folgendermaßen aussehen:
<log>
<application>
<path>C:\Users\bob\downloadclient</path>
<level>INFO</level>
<size_m>10</size_m>
<name>dlc_app_log_</name>
</application>
<download>
<path></path>
<level>DEBUG</level>
<size_m>10</size_m>
<name>dlc_download_log_</name>
</download>
<status>
<path></path>
<level>INFO</level>
<size_m></size_m>
<name></name>
</status>
</log>
Dabei wird auf eine sinnvolle Vorbelegung geachtet; Beispielsweise: Wenn unter "application" kein Pfad angegeben ist, so wird alles nach {Temp-Ordner-des-Systems}/downloadclient geleitet oder wenn unter "download" kein Pfad angegeben ist, in den angegebenen Download Ordner (wie bisher) gespeichert wird.
So wird die Möglichkeit hergestellt, dass alle Logs dynamisch konfiguriert und gespeichert werden können. Ein konfigurierbares Muster im Dateinamen, wie "yyyymmdd" ist dabei nicht vorgesehen, da die Umsetzung dafür mitunter sehr Zeitaufwändig ist.
Bis zur Klärung des obigen Implementiervorschlages wird die weitere Umsetzung von #40 gestoppt.
Mit https://github.com/gdi-by/downloadclient/pull/84 steht dies nun zur Verfügung. Ein Request-log wird wie in https://github.com/gdi-by/downloadclient/issues/40#issuecomment-306761991 und davor beschrieben angelegt.
Alle Requests sollen in einem Anwendungslog als
.txt-Datei
protokolliert werden.