Ich habe ein Bibliotheksprojekt. Dieses Projekt verwendet log4j für die Protokollierung.Sollte ich log4j.properties Datei in die Bibliothek legen?
Sollte ich log4j.properties in generierte jar?
Wenn es keine gute Praxis ist, könnten Sie mir sagen, warum?
Sie sollten Ihre log4j.properties außerhalb Ihrer JAR-Datei platzieren, da es einfacher ist, sie zu ändern. Wenn die Anwendung kein Neuladen der Konfiguration erzwingt (Sie können das tun), lädt ein einfacher Neustart die Konfiguration (während das Ändern in einer JAR-Datei normalerweise eine Neuerstellung bedeutet). Wenn die Anwendung weiß, wie sie neu geladen wird, werden Ihre Änderungen fast sofort übernommen. Dies ist sehr wichtig, wenn Sie eine Anwendung in der Produktionsumgebung haben und eine Protokollierungseinstellung (wie die Protokollierungsstufe) ändern möchten, um weitere Informationen zu erhalten, die Anwendung jedoch nicht zu stoppen (oder schlimmer noch, sie neu aufzubauen).
Nein, ich würde log4j.properties in Ihrem src/main/resources nicht einschließen, wenn es nur eine Bibliothek ist - Leute benutzen Ihre Bibliothek, und Leute müssen konfigurieren, wie es loggen sollte.
Aber es gibt ein anderes Problem: Wenn Sie es in Ihr Glas legen, haben andere das log4j in ihrem Klassenpfad auch. Also, wenn sie eine benutzerdefinierte Konfiguration für log4j haben wollen (was sie tun werden), wird der ClassLoader die erste Datei auswählen, die er finden kann.
Auch wenn Sie eine Bibliothek haben, würde ich vorschlagen, stattdessen slf4j zu verwenden, damit Ihre Benutzer ihre bevorzugte Protokollierung Rahmen wählen können.
Für Testzwecke ist es in Ordnung, log4j in src/test/resources aufzunehmen.
Ich glaube nicht, dass OP irgendetwas über Maven erwähnt hat. src/main/resources und src/test/resources sind Maven-Konzepte. Ansonsten stimme ich zu. – eis
All dies trifft zu und gilt auch für Anwendungsbereitstellungen. Es gibt weitere Gründe, es nicht in ein * library * -Projekt zu legen - nämlich, dass Sie normalerweise nicht wissen, in welchem Kontext es verwendet wird und welche Konfiguration den Klassenpfad beeinflusst, was mögliche Probleme verursacht. – eis
Die Möglichkeit, Debugging auf einem Server während eines Fehlers zu aktivieren, ist ein Lebensretter. So sehr wir es auch testen, schützt es nur vor den Problemen, die wir testen wollten. Die Möglichkeit, zusätzliche Details zu den Geschehnissen zu erhalten, führt direkt zu besseren Tests in der Zukunft. – Gus