- logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-241) Set the logback to rollover new files every x minutes
by moo mik ki (JIRA) 16 Dec '11

16 Dec '11

Set the logback to rollover new files every x minutes ----------------------------------------------------- Key: LBCORE-241 URL: http://jira.qos.ch/browse/LBCORE-241 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: 0.9.21 Reporter: moo mik ki Assignee: Logback dev list Dear dev, I tried one of the solutions here .periodictimebasedfilenamingandtrigerringpolicy but its not working. I tried to include it in my system which the requirements requires me to create new log file every 5 minutes. Please help me with my university project. thank you. xml : <?xml version="1.0" encoding="UTF-8" ?> <configuration scan="true" scanPeriod="60 seconds"> <appender name="my_appender" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>F:/Logs/Server.log</File> <encoder> <Pattern>Server[%d{ISO8601}][%p] - %m%n</Pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>F:/Logs/Server-%d{yyyy-MM-dd_HH-mm-ss}.log</FileNamePattern> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.PeriodicTimeBasedFileNamingAndTriggeringPolicy"> <period>600</period> </triggeringPolicy> </appender> <logger name="com.mypackage.application" level="debug" additivity="false"> <appender-ref ref="my_appender" /> </logger> </configuration> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBCLASSIC-314) caller should accept a full or short depth
by Pierre-Luc Charette (JIRA) 12 Dec '11

12 Dec '11

caller should accept a full or short depth ------------------------------------------ Key: LBCLASSIC-314 URL: http://jira.qos.ch/browse/LBCLASSIC-314 Project: logback-classic Issue Type: Improvement Components: layout Affects Versions: 1.0.0 Reporter: Pierre-Luc Charette Assignee: Logback dev list Priority: Trivial The caller converter should accept a depth of full or short like the exception converter. For now, the caller can only accept an integer as its depth. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBCLASSIC-284) Make it possible to log to different appenders at different levels from the same logger
by Iwein Fuld (JIRA) 10 Dec '11

10 Dec '11

Make it possible to log to different appenders at different levels from the same logger --------------------------------------------------------------------------------------- Key: LBCLASSIC-284 URL: http://jira.qos.ch/browse/LBCLASSIC-284 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.28 Reporter: Iwein Fuld Assignee: Logback dev list I found a requirement in the wild to log trace and above statements to one appender, and debug and above to another. This needed to be configured for a particular package. My preferred solution would be to use something like https://gist.github.com/1104145, but that doesn't work. There is a workaround of using a filter inside the appender, but that isn't as pretty as I would like. ( http://iweinfuld.posterous.com/ ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBCLASSIC-313) Load properties from xml
by Pierre-Luc Charette (JIRA) 08 Dec '11

08 Dec '11

Load properties from xml ------------------------ Key: LBCLASSIC-313 URL: http://jira.qos.ch/browse/LBCLASSIC-313 Project: logback-classic Issue Type: New Feature Components: joran Affects Versions: 1.0.0 Reporter: Pierre-Luc Charette Assignee: Logback dev list There is no way to load a properties file in xml. There could be a a xmlFile attribute used to call java.util.Properties.loadFromXML like file does for Properties.load. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBCORE-240) from with pattern in SMTPAppender
by Pierre-Luc Charette (JIRA) 08 Dec '11

08 Dec '11

from with pattern in SMTPAppender --------------------------------- Key: LBCORE-240 URL: http://jira.qos.ch/browse/LBCORE-240 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 1.0.0 Reporter: Pierre-Luc Charette Assignee: Logback dev list Priority: Minor It would be useful to put a pattern in the from address of the SMTPAppender. For example, if you have, like me, a multi-user login and you want to know the complete name of the person logged in, you need to wait after the login to fill a MDC property with it. I could also put the right user email in the field after login. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBCLASSIC-311) Facade method for configuration by xml: Programmatic configuration should be a single line
by Geoffrey De Smet (JIRA) 04 Dec '11

04 Dec '11

Facade method for configuration by xml: Programmatic configuration should be a single line ------------------------------------------------------------------------------------------ Key: LBCLASSIC-311 URL: http://jira.qos.ch/browse/LBCLASSIC-311 Project: logback-classic Issue Type: New Feature Components: joran Affects Versions: 1.0.0 Reporter: Geoffrey De Smet Assignee: Logback dev list >From a user's perspective, it doesn't a bit overkill to copy paste all this stuff: {code} LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(context); // Call context.reset() to clear any previous configuration, e.g. default // configuration. For multi-step configuration, omit calling context.reset(). context.reset(); configurator.doConfigure(getClass.getResource("/com/domain/project/logback.xml")); } catch (JoranException je) { // StatusPrinter will handle this } StatusPrinter.printInCaseOfErrorsOrWarnings(context); {code} It would be nicer if we had a simple static facade method, on JoranConfigurator or LoggerContext, that does all that stuff: {code} JoranConfigurator.configure(getClass.getResource("/com/domain/project/logback.xml")); {code} We shouldn't need to understand the internals and the lifecycle of the JoranConfigurator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBCLASSIC-310) ReconfigureOnChangeFilter should re-use substition properties from initial configuration
by Gunnar Wagenknecht (JIRA) 02 Dec '11

02 Dec '11

ReconfigureOnChangeFilter should re-use substition properties from initial configuration ---------------------------------------------------------------------------------------- Key: LBCLASSIC-310 URL: http://jira.qos.ch/browse/LBCLASSIC-310 Project: logback-classic Issue Type: Improvement Components: joran Affects Versions: 0.9.27 Reporter: Gunnar Wagenknecht Assignee: Logback dev list Logback configuration files are automatically reloaded when {{scan="true"}} is set. This is implemented using {{ReconfigureOnChangeFilter}}. The actually re-configuration happens in {{ReconfiguringThread}} which always creates a new default {{JoranConfigurator}}. This is works as long as the initial {{JoranConfigurator}} hasn't been extended to support additional substitution properties. {code:java} // create our customized configurator final JoranConfigurator configurator = new JoranConfigurator() { @Override protected void addImplicitRules(final Interpreter interpreter) { super.addImplicitRules(interpreter); // set some properties for log file substitution if (null != instanceLogfileDirectory) { interpreter.getInterpretationContext().addSubstitutionProperty("my.property", calculateMyPropertyValue()); } } }; {code} It should somehow be possible to inherit the custom substitution properties into the new {{JoranConfigurator}}. Otherwise they are lost on re-configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBGENERAL-49) Logback does not pass turkey test
by Sebastian Davids (JIRA) 01 Dec '11

01 Dec '11

Logback does not pass turkey test --------------------------------- Key: LBGENERAL-49 URL: http://jira.qos.ch/browse/LBGENERAL-49 Project: logback-general Issue Type: Bug Affects Versions: 1.0.0 Reporter: Sebastian Davids Assignee: Logback dev list import java.io.Serializable; import java.util.ArrayList; import java.util.List; public class Bean implements Serializable { private static final long serialVersionUID = 1957667958813006175L; private List<String> iceCreams = new ArrayList<String>(); public void addIceCream(String iceCream) { iceCreams.add(iceCream); } @Override public String toString() { return iceCreams.toString(); } } //// import java.beans.Introspector; import java.util.Locale; import org.slf4j.LoggerFactory; import ch.qos.logback.classic.Level; import ch.qos.logback.classic.Logger; import ch.qos.logback.classic.html.HTMLLayout; import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.classic.spi.LoggingEvent; import ch.qos.logback.core.ContextBase; import ch.qos.logback.core.joran.util.PropertySetter; public class Main { public static void main(String[] args) { Bean bean = new Bean(); PropertySetter setter = new PropertySetter(bean); setter.setContext(new ContextBase()); String propertyName = "iceCream"; setter.addBasicProperty(propertyName, "vanilla"); System.out.println(bean); System.out.println(propertyName.toUpperCase()); Locale.setDefault(new Locale("tr", "", "")); setter.addBasicProperty(propertyName, "chocolate"); System.out.println(bean); System.out.println(propertyName.toUpperCase()); System.out.println(Introspector.decapitalize("IceCream")); System.out.println("I".toLowerCase() + "ceCream"); System.out.println(capitalizeFirstLetter(propertyName)); System.out.println("i".toUpperCase() + "ceCream"); Logger logger = (Logger) LoggerFactory.getLogger("iAmALogger"); Level level = Level.INFO; ILoggingEvent event = new LoggingEvent("iAmALoggingEvent", logger, level, "i am logging", null, null); System.out.println(event); HTMLLayout layout = new HTMLLayout(); String html = layout.doLayout(event); System.out.println(html); } public static String capitalizeFirstLetter(String name) { if (name == null || name.length() == 0) { return name; } char chars[] = name.toCharArray(); chars[0] = Character.toUpperCase(chars[0]); return new String(chars); } } @@ Output @@ [vanilla] ICECREAM [vanilla] İCECREAM iceCream ıceCream IceCream İceCream [INFO] i am logging <tr class="ınfo even"> </tr> @@@@ http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 5

[JIRA] Created: (LBCORE-238) Small refactoring of ch.qos.logback.core.joran.action.PropertyAction#stringToScope
by Sebastian Davids (JIRA) 01 Dec '11

01 Dec '11

Small refactoring of ch.qos.logback.core.joran.action.PropertyAction#stringToScope ---------------------------------------------------------------------------------- Key: LBCORE-238 URL: http://jira.qos.ch/browse/LBCORE-238 Project: logback-core Issue Type: Improvement Components: Joran Affects Versions: 1.0.0 Reporter: Sebastian Davids Assignee: Logback dev list Priority: Minor private Scope stringToScope(String scopeStr) { for (Scope scope : Scope.values()) { if (scope.name().equalsIgnoreCase(scopeStr)) return scope; } return Scope.LOCAL; } ///// If you introduce further scopes down the road you do not have to modify this code again -- the current switch statement would have to be modified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

Logback initialization time analysis
by Phil Clay 22 Nov '11

22 Nov '11

In an effort to speed up a CLI program that uses slf4j and logback, I've done some analysis on logback initialization time. This came about because logback initialization was dominating our CLI execution time. Mainly this was because of XML configuration. Therefore, in our CLIs, I have replaced XML configuration with programmatic configuration in java. This reduced the logback initialization overhead drastically. But I wanted to analyze this further to see if more enhancements could be made. With the yourkit profiler, I identified several 'hotspots' in the code and made various tweeks to remove those hotspots. I measured each change individually to see what kind of benefit (if any) it gave. Skip down to the CONCLUSION if you don't care about the details. == TEST SETUP == I created a class as follows: public class LoggerInitTest { public static void main(String[] args) { LoggerFactory.getILoggerFactory(); } } No xml or grovy configuration files exist on the classpath. XML/groovy configuration is expensive. We get the greatest benefit by just not using it, so I didn't bother trying to speed it up. == TEST EXECUTION == Each case below was executed 200 times from the cli. (i.e. the loop was in bash, not java). The min/max/avg times were calculated for each case. == TEST CASE A == Baseline test case using slf4j-nop instead of logback. == TEST CASE B == logback 0.9.29 (unmodified) == TEST CASE C == logback 1.0.1 (unmodified) Git cloned last week. Don't have the exact change number in front of me... == TEST CASE D == logback 1.0.1 with the following modification 1) Loader.HAS_GET_CLASS_LOADER_PERMISSION converted to be lazily initialized See attached 1_Loader.diff Classloading the Loader class was identified as a hotspot because of static initialization. By lazily loading HAS_GET_CLASS_LOADER_PERMISSION, we can avoid the performance hit unless it is needed. In my CLIs, HAS_GET_CLASS_LOADER_PERMISSION is never needed, therefore the initialization cost is completely avoided. == TEST CASE E == logback 1.0.1 with the following modifications 1) (from above) 2) ContextBase.executorService converted to be lazily initialized See attached 2_ContextBase.diff Initializing the executorService was identified as a hotspot. By lazily loading executorService, we can avoid the performance hit unless it is needed. In my tests, executorService is never needed. == TEST CASE F == logback 1.0.1 with the following modifications 1) (from above) 2) (from above) 3) PatternLayout.defaultConverterMap classes lazily loaded See attached 3_PatternLayout.diff Since the classnames are populated in the defaultConverterMap by statically referencing the class, and calling getName(). For example: ch.qos.logback.classic.pattern.DateConverter.class.getName(); This causes all of the converter classes to be loaded, even if they are not used. I converted the classnames to be string literals instead. For example: "ch.qos.logback.classic.pattern.DateConverter" This allows the converter classes to not be loaded until/unless they are actually used. I don't need many of the converters. The downside of this change is that you lose compile-time safety on the class names. == TEST CASE G == logback 1.0.1 with the following modifications 1) (from above) 2) (from above) 3) (from above) Also, The LoggerInitTest class was modified to perform additional configuration beyond BasicConfigurator This test case is to provide a baseline to see if the change proposed in http://jira.qos.ch/browse/LBCLASSIC-300 has any benefit. == TEST CASE H == logback 1.0.1 with the following modifications 1) (from above) 2) (from above) 3) (from above) 4) ContextInitializer changed to allow configuration by java class (and skip configuration file lookup and BasicConfigurator logic). See attached 4_ContextInitializer.diff The LoggerInitTest class was modified to provide LoggerContext configuration (via hook into #4). Therefore the logic to search the classpath for XML/groovy files and the configuration logic in BasicConfigurator was avoided. The results of this test case can be compared against test case #G to see if the change proposed in http://jira.qos.ch/browse/LBCLASSIC-300 has any benefit. == TEST RESULTS == Numbers are in milliseconds. Case min max avg A 131 247 165 B 281 496 293 C 331 546 347 D 282 499 296 E 281 496 292 F 280 450 287 G 282 492 307 H 282 450 300 See this in graph form in attached results.png == ANALYSIS == Initialization time increased significantly between (B) 0.9.29 and (C) the current 1.0.1 head. After change #1 from (D) was made, performance was back on-par with 0.9.29. I identified that the HAS_GET_CLASS_LOADER_PERMISSION was introduced after 0.9.29 (http://jira.qos.ch/browse/LBCLASSIC-263) so this is further evidence that this caused the increase seen in (C). None of the other changes from E, F, G, or H, had any noticable impact to initialization performance. When profiling with yourkit, I can see the performance difference. But, when executing the test without profiling, no change can be seen. I was unable to make any changes that decreased initialization time below that of (B) 0.9.29. After further profiling of individual tests runs with yourkit, I can see that most of the initialization time is spent in the following areas: - classloading (mainly because of static initialization) - Pattern compiling / parsing I could not identify any other places to reduce the number of classes loaded by logback. == CONCLUSION == The only change that I can recommend incorporating into logback to decrease initialization time is from test case (D): 1) Loader.HAS_GET_CLASS_LOADER_PERMISSION converted to be lazily initialized See attached 1_Loader.diff This would get initialization time of 1.0.1 back down to the initialization time of (B) 0.9.29. == ACTION ITEMS == I'll file a JIRA issue for incorporating change #1 into logback. I'm going to close http://jira.qos.ch/browse/LBCLASSIC-300 (filed by me) because the proposed change had no impact to initialization performance. If you have any other suggestions on ways to improve initialization performance, please let me know. Other thoughts are welcome as well. Thanks, Phil

4 5