2010-05-05 8 views
24

Ich habe eine Anwendung, bestehend aus einem Host und Pluggable-Module (Plugins).log4net - Konfiguration mit mehreren Konfigurationsdateien

Ich möchte log4net für den Host und für jedes der anderen Module konfigurieren können. Jeder von ihnen sollte seine eigene Konfigurationsdatei haben und jeder wird in einer anderen Datei protokollieren.

Nur der Host verfügt über eine App.config-Datei. Die Plugins haben ihre eigene Konfigurationsdatei, die die log4net-Konfigurationsabschnitte enthält.

Der Aufruf von XmlConfigurator.Configure von einem der Plugins überschreibt die app.config log4net-Definitionen des Hosts.

Gibt es eine einfache Möglichkeit, Konfigurationen anzuhängen anstatt sie zu überschreiben?

Danke, Gai.

Antwort

2

Ich bin gerade selbst auf dieses Problem gestoßen. Obwohl es nicht genau das ist, was ich "ideal" nennen würde, denke ich, dass die beste Lösung derzeit die ConfigureAndWatch Methode der XmlConfigurator Klasse ist. Im Grunde genommen hat Ihre Host-Assembly die log4net-Konfiguration mit einer bestimmten Konfigurationsdatei eingerichtet. Wenn Ihre Plugins geladen werden, lassen Sie sie ihre Konfigurationselemente in den Konfigurationsabschnitt von log4net in derselben Konfigurationsdatei schreiben. Da log4net aufgefordert wurde, diese Datei auf Änderungen mit ConfigureAndWatch zu überwachen, lädt log4net die Konfiguration neu, wenn die Datei diese neuen Daten hinzugefügt hat, und enthält nun die Konfigurationselemente aus den Plugins.

Dies ist ein bisschen hackish, aber es scheint zu funktionieren. Der nächste Schritt wird natürlich in mein Logging-Framework verschoben, damit der Zugriff auf die Konfigurationsdatei eingebunden wird.

Beachten Sie, dass es eine kurze Verzögerung zwischen der geschriebenen/gespeicherten Konfiguration des Plugins und der aktualisierten Konfiguration gibt, die neu geladen und auf das Logger-Repository angewendet wird.

+0

Dank Stuart, werde ich es versuchen. – Gai

16

Es scheint, dass Sie bereits eine Lösung gefunden haben, die für Sie arbeitet. Ich habe jedoch eine andere Lösung gefunden, die ich für "ideal" halte, also werde ich sie hier veröffentlichen für diejenigen, die diese Frage in der Zukunft finden könnten.

log4net hat ein Konzept namens Repositories, die separat konfiguriert werden können. Es ist nicht sehr beliebt, noch sehr gut dokumentiert, aber hier ist einige Dokumentation ich gefunden:

http://logging.apache.org/log4net/release/manual/repositories.html

Wie auch immer, alles, was Sie tun müssen, ist RepositoryAttribute auf Ihrem Plugin Assembly hinzufügen oder Baugruppen mit einem Repository Name eindeutig zu diesem Plugin und log4net wird es von allem anderen trennen.

4

Noch eine andere Möglichkeit besteht darin, mehrere log4net-Konfigurationsdateien an mehreren Stellen zu speichern, sie alle in eine XDocument zu laden, um effektiv eine einzige zu erstellen, und dann XmlConfigurator.Configure() anrufen. Die Vorgehensweise bestand darin, jede Datei nach dem XSD für die Konfiguration zu erstellen, alle untergeordneten Knoten des Stammknotens jeder Datei in separate XElement Instanzen zu laden und sie zu einem neuen XDocument mit einem Stammknoten log4net zusammenzuführen. Ich werde diese Antwort mit dem Code aktualisieren (es ist im Moment nicht vor mir), wenn jemand weiter interessiert ist.

Das Finden der Dateien ist eine andere Sache: Verwenden Sie eine Art Konvention, um nach Dateien zu suchen (z. B. *.dll.log4net.config), betten Sie sie in die Assemblys oder etwas ein.

Eine Implementierung eines solchen Codes finden Sie unter:

www.kopf.com.br/kaplof/using-multiple-configuration-files-with-log4net

+0

Wie würdest du das machen? Klingt nach einer guten Lösung. Es scheint nicht trivial zu sein, da Sie nur ein einziges "log4net" -Tag behalten und den Inhalt dieses Tags zusammenführen müssen. – Wayne

+0

Ich aktualisierte meine Antwort mit ein bisschen mehr Details. Es stellt sich heraus, dass nicht zu viel Code benötigt wird, und es lohnt sich, unterschiedliche Protokollierungseinstellungen pro Umgebung zu verwenden, ohne auf zusätzliche Build-Schritte zurückgreifen zu müssen. – Kit