log4j: unterschiedliche Verwendung von stdout Datei/console, wenn in der Produktion/Entwicklung

Question

In unserem Unternehmen haben wir eine log4j Konfiguration haben, wie folgt:

Strom in der Konsole geht

log4j.rootLogger=INFO, CATALINA, stdout 

# Used only for development. 
log4j.appender.stdout=org.apache.log4j.ConsoleAppender 
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout 
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n 

# Define all the appenders 
# configurazione catalina con meteodo di rotazione in base alla size 
log4j.appender.CATALINA=org.apache.log4j.RollingFileAppender 
log4j.appender.CATALINA.File=${catalina.base}/logs/catalina. 
log4j.appender.CATALINA.Encoding=UTF-8 
log4j.appender.CATALINA.MaxFileSize=100MB 
log4j.appender.CATALINA.MaxBackupIndex=10 
log4j.appender.CATALINA.layout=org.apache.log4j.PatternLayout 
log4j.appender.CATALINA.layout.ConversionPattern=%d %p %t %c - %m%n 




# Log all JDBC parameters 
log4j.logger.org.hibernate.SQL=TRACE 
log4j.logger.com.mchange.v2.c3p0=DEBUG 

Unsere stdout, wenn wir entwickeln und in einer rotierenden Datei Appender.

Da wir unsere Dateien manuell zur Veröffentlichung in der Produktion verpacken, kommentieren wir diese 3 Zeilen und den Stdout-Teil der ersten Zeile manuell. JEDES MAL

# Used only for development. 
log4j.appender.stdout=org.apache.log4j.ConsoleAppender 
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout 
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n 

in bedeutet dabei vergessend, so dass wir eine stdout-Datei haben, die die gleichen Informationen der CATALINA Roll Datei appender enthalten wird, wird aber nicht rollen, wird so wachsen auf unbestimmte Zeit, bis Speicherplatz zu sättigen und zur gleichen Zeit nutzlos sein.

Gibt es eine Möglichkeit, eine log4j-Konfiguration zu haben, die wir nicht jedes Mal ändern müssen?

Answer 1

Es gibt nur eine Antwort, die Sinn macht, wenn Sie Ihren Kommentar über die Verwendung eines Build-Systems geben: Beginnen Sie, einen jetzt zu ziehen. Wenn Sie ernsthaft über professionelle Software-Entwicklung, dann sollten Sie professionelle Prozesse verwenden.

Was Sie im Grunde sagen, ist: "Wir tun nicht die obligatorischen Dinge; und autsch, das tut weh, bitte mach den Schmerz weg".

Entschuldigung, aber die einfache Antwort darauf ist: die nur Alternative zur manuellen Verarbeitung .. ist ** Automatisierung. Also baue das, oder lebe mit den Konsequenzen, wenn du das nicht tust.

Natürlich können Sie solche Dinge nicht über Nacht tun, aber hey: Der Rest der Welt spricht über "Continuous Build" wahrscheinlich für 10+ Jahre und über "kontinuierliche Lieferung", auch bekannt als DevOps für 3+ Jahre. Und Sie haben kein eingebautes System ?!

Dies soll nicht unhöflich sein, aber es scheint, dass Ihre Software-Prozesse aus dem letzten Jahrtausend stammen; Anstatt sich darum zu kümmern, wie man dieses Symptom ... heilen kann, treten Sie besser zurück und machen eine vollständige Diagnose Ihrer kompletten Entwicklungskette. Und dann fängst du an, es zu reparieren. Sie werden wahrscheinlich viele andere kleine Probleme entdecken; Und je früher Sie anfangen, desto früher werden Sie in der Lage sein, enorme Effizienzgewinne einzufahren.

Und wissen Sie, ich glaube, es Unternehmen waren da draußen, die erfolgreichen Produkte hatten, dass irgendwann gestorben - denn früher oder später, wie manuelle Prozesse zu schrecklichen Fehlern führen, Wanzen, Kundensituationen, ...