Android Logback SizeBasedTriggeringPolicy nicht triggern

Question

Ich benutze Logback für Android, und ich bin es in Code konfigurieren, weil ich das Log-Verzeichnis dynamisch abhängig vom Telefon ändern möchte (zB einige Telefone haben externen Speicher und ich möchte schreiben das, aber andere Telefone nicht so müssen wir zum internen Speicher umleiten).

Hier ist mein Config-Code:

File logFilesDir = getLogFilesDir(this); 
LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); 
lc.reset(); 

RollingFileAppender<ILoggingEvent> fileAppender = null; 
lc.putProperty("LOG_DIR", logFilesDir.getAbsolutePath()); 

PatternLayoutEncoder encoder = new PatternLayoutEncoder(); 
encoder.setContext(lc); 
encoder.setPattern("%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"); 
encoder.start(); 

File logFile = new File(logFilesDir, "MyApplication.log"); 

FixedWindowRollingPolicy rollingPolicy = new FixedWindowRollingPolicy(); 
rollingPolicy.setContext(lc); 
rollingPolicy.setFileNamePattern("${LOG_DIR}/MyApplication.%i.log"); 
rollingPolicy.setMinIndex(1); 
rollingPolicy.setMaxIndex(5); 

SizeBasedTriggeringPolicy<ILoggingEvent> triggeringPolicy = new SizeBasedTriggeringPolicy<>(); 
triggeringPolicy.setContext(lc); 
triggeringPolicy.setMaxFileSize("1KB"); // for testing; would otherwise be 5MB 

fileAppender = new RollingFileAppender<>(); 
fileAppender.setContext(lc); 
fileAppender.setFile(logFile.getAbsolutePath()); 
fileAppender.setEncoder(encoder); 
fileAppender.setRollingPolicy(rollingPolicy); 
fileAppender.setTriggeringPolicy(triggeringPolicy); 

rollingPolicy.setParent(fileAppender); 

fileAppender.start(); 
rollingPolicy.start(); 
triggeringPolicy.start(); 

// add the newly created appenders to the root logger; 
// qualify Logger to disambiguate from org.slf4j.Logger 
ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME); 
root.addAppender(fileAppender); 

root.info("----- Application onCreate -----"); 
StatusPrinter.print(lc); 

Das Protokoll schreibt in den richtigen Ordnern und es ist alles in Ordnung arbeiten, außer wenn meine Größe der Protokolldatei der maximalen Datei überschreitet (in 1 KB meines Testfalls) es nicht zu sich umdrehen. Stattdessen wächst die Datei einfach weiter.

StatusPrinter.print schreibt die folgende Ausgabe, die wie alles in Ordnung aussieht

|-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [assets/logback.xml] 
|-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: /storage/emulated/0/MyApplication/logs/MyApplication.log 
|-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [/storage/emulated/0/MyApplication/logs/MyApplication.log] 
|-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@34b71b53 - No compression will be used 

Ich habe an so viele anderen ähnlichen Problemen sieht, wie ich finden kann, und in der Regel scheinen die Menschen die RollingFileAppender zu verpassen oder nicht habe die Berechtigung WRITE_EXTERNAL_STORAGE ... Es scheint mir nicht, als würde ich einen dieser Fälle treffen. Ist etwas an meinem Code (anders als die XML-Leute normalerweise) anders?

Gibt es etwas, was ich tun kann, um dies zu beheben oder es weiter zu beheben?

Dank

Answer 1

ich nicht sofort sagen kann, was das Problem ist, aber es wäre ein OnConsoleStatusListener hinzufügen, um zu sehen, was während des Überschlags geschieht hilfreich sein:

LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); 
lc.reset(); 
OnConsoleStatusListener.addNewInstanceToContext(lc); 

Prolongation Probleme von RollingFileAppender sind in der Regel verursacht durch eine Mischung aus absoluten und relativen Pfaden in ihrer Konfiguration (Issue #117, Issue #110) oder fehlt die WRITE_EXTERNAL_STORAGE Erlaubnis (was für Sie nicht der Fall ist). Die Debugausgabe von OnConsoleStatusListener könnte etwas Licht werfen. Wenn nicht, kann ich versuchen, es zu debuggen, wenn Sie ein GitHub Issue erstellen, vorzugsweise mit einem Android Studio-Projekt, das das Problem reproduziert.