Geek Answers Handbook

Logback manually causes rollover

Using logback, I would like to start a new log every time an asynchronous job starts, so I need to trigger a rollover manually. But when I try to get the appender, I get null instead. Below is my configuration:

<configuration scan="true"> <timestamp key="time" datePattern="yyyy-MM-dd_HH_mm"/> <logger name="com.my.com.pany" level="DEBUG"> <appender name="TEST" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/log_TEST_${time}.log</file> <triggeringPolicy class="com.my.com.pany.myapp.logging.ManualRollingPolicy"> </triggeringPolicy> <append>true</append> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> </logger> </configuration>

I trigger the rollover as follows:

  ch.qos.logback.classic.Logger logF = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.my.com.pany"); RollingFileAppender<ILoggingEvent> appender = (RollingFileAppender<ILoggingEvent>) logF.getAppender("test"); appender.rollover();

I extended TimeBasedRollingPolicy<E> so that my log starts when I start async:

 @NoAutoStart public class ManualRollingPolicy<E> extends TimeBasedRollingPolicy<E> { }

Can someone help me on this? EDIT: After some further research, I see that LogF has a size 1 appenderList that my custom RollingPolicy configured RollingPolicy . However, the name property of this appender is null, and I think that is why I cannot get it by name.

+5
source share
2 answers

So, I got a pretty neat workaround, which, in my opinion, might be useful. You can use SiftingAppender . "As its name implies, SiftingAppender can be used to split (or sort) the log according to the specified runtime attribute

Thus, you configure your appender to get some unique parameter in my batch job launch date:

 <appender name="FULL" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <key>id</key> <defaultValue>000000</defaultValue> </discriminator> <sift> <appender name="FULL-${id}" class="ch.qos.logback.core.FileAppender"> <file>logs/log_${id}.log</file> <append>false</append> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </layout> </appender> </sift> </appender>

And then you manually call: MDC.put("id",id); to start a new log, and when you are done with this paticular log file, you simply write the FINALIZE_SESSION_MARKER constant: logger.info(ClassicConstants.FINALIZE_SESSION_MARKER) . In my opinion, it is flexible enough that it answers the question of manuall readjustment.

+5
source

I finally figured out how you can do this. In case someone else stumbles upon this question.

for manual tipping:

 public static void manuallyRolloverLog() { ch.qos.logback.classic.Logger log = (ch.qos.logback.classic.Logger)LoggerFactory.getLogger(MainActivity.class); RollingFileAppender file = (RollingFileAppender) log.getAppender("FILE"); file.rollover(); }

The XML configuration used is as follows:

 <configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>AppLog.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>AppLog.%i.log.zip</fileNamePattern> <minIndex>1</minIndex> <maxIndex>3</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>5MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%d %-5level %logger{35} - %msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root>

This will make the drag and drop to fit and allow you to manually flip the request.

+2
source

More articles:


All Articles