June 2012 - logback-user - mailman3.qos.ch

stack trace does not print - sometimes
by David Tkaczyk 06 Jun '12

06 Jun '12

Hi, I have a situation where the same line of code in some cases produces a stack trace and in other cases does not. I have not been able to reproduce this in a unit test. Has anyone ever seen this? I'm using this pattern: <pattern>%date{yyyy-MM-dd HH:mm:ss.SSS} %-6camlevel [%thread] %class.%method:%line - %message %mdc%n</pattern> Here's the offending line of code - 581: logger.warn( MessageFormatter.format("Rejecting {} due to error: ", object) .getMessage(), exc); "object" is an Object and "exc" is an Exception Example w/o stack trace: 2012-06-06 04:10:25.616 WARN [DiameterEnfManager8] msc.rc.diameter.DiameterEnfManager.handleObject:581 - Rejecting CREATE SessionId=seagull_gx;atcaa;b;c;d Subscriber=[IMSI:xxxxxxxx, IP:yyyyyyyyyy] due to error: java.lang.NullPointerException: null Example w/ stack trace: 2012-06-06 04:14:18.727 WARN [DiameterEnfManager2] msc.rc.diameter.DiameterEnfManager.handleObject:581 - Rejecting REAUTHACK SessionId=seagull_gxx;atca Subscriber=[IP:aaaaa, IMSI:zzzzzzzzzzzzzzzzz] due to error: java.util.ConcurrentModificationException: null at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) ~[na:1.7.0_02] at java.util.ArrayList$Itr.next(ArrayList.java:791) ~[na:1.7.0_02] at msc.rc.model.ObjectFactory.getSessionAltKeys(ObjectFactory.java:4024) ~[msc.jar:na] at msc.rc.diameter.model.DiameterObjectFactory.saveSession(DiameterObjectFactor y.java:752) ~[msc.jar:na] at msc.rc.diameter.DiameterManager.saveSession(DiameterManager.java:595) ~[msc.jar:na] at msc.rc.diameter.DiameterManager.handleAck(DiameterManager.java:732) ~[msc.jar:na] at msc.rc.diameter.DiameterEnfManager.handleAck(DiameterEnfManager.java:3854) ~[msc.jar:na] at msc.rc.diameter.DiameterEnfManager.handleObject(DiameterEnfManager.java:527) ~[msc.jar:na] at msc.rc.framework.HandlerThreadTracker.handleObject(HandlerThreadTracker.java :51) [msc.jar:na] at msc.rc.framework.QueueHandlerThread.run(QueueHandlerThread.java:103) [msc.jar:na] at abc.util.thread.ManagedThread$ExceptionHandler.run(ManagedThread.java:230) [camiant-platform.jar:na] at java.lang.Thread.run(Thread.java:722) [na:1.7.0_02] Thanks, Dave

2 2

Re: [logback-user] Localized log level names
by Dario Campagna 05 Jun '12

05 Jun '12

Hi Ceki, > Thanks for sharing this code. It's probably a minor detail but instead > of switching on a String which requires JDK 7, you could switch on the > integer corresponding to a Level. The Level.toInt() method [1] returns > this integer. The integer constant for DEBUG is given by > Level.DEBUG_INT [2], for INFO by Level.INFO_INT and so forth. Ok, thank for your suggestion. > BTW, the code for the Levels enum is missing. For future reference, it > would be very nice if you could create a github project for this code. I just created a github project for my custom level converter, here is the link https://github.com/dario-campagna/CAL10N-level-converter Cheers, Dario

1 0

Re: [logback-user] Localized log level names
by Dario Campagna 05 Jun '12

05 Jun '12

Hi all, Another update regarding the localization of log level names. I made some modifications to the custom converter for level names localization I implemented following Ceki's suggestion (i.e., CAL10NLevelConverter). The following is the converter I obtained. public class CAL10NLevelConverter extends ClassicConverter { private static String LOC_TRACE = locLevelName("TRACE"); private static String LOC_DEBUG = locLevelName("DEBUG"); private static String LOC_INFO = locLevelName("INFO"); private static String LOC_WARN = locLevelName("WARN"); private static String LOC_ERROR = locLevelName("ERROR"); @Override public String convert(ILoggingEvent event) { Level level = event.getLevel(); String locLevelName; switch (level.toString()) { case "TRACE": locLevelName = LOC_TRACE; break; case "DEBUG": locLevelName = LOC_DEBUG; break; case "INFO": locLevelName = LOC_INFO; break; case "WARN": locLevelName = LOC_WARN; break; case "ERROR": locLevelName = LOC_ERROR; break; default: locLevelName = LOC_DEBUG; } return locLevelName; } private static String locLevelName(String levelName) { IMessageConveyor mc = new MessageConveyor(Locale.getDefault()); Enum<Levels> key; switch (levelName) { case "TRACE": key = Levels.TRACE; break; case "DEBUG": key = Levels.DEBUG; break; case "INFO": key = Levels.INFO; break; case "WARN": key = Levels.WARN; break; case "ERROR": key = Levels.ERROR; break; default: key = Levels.DEBUG; } return mc.getMessage(key); } } Thanks to the static attributes I manged to reduce the number of invocations to the method MakePropertyResourceBoundle of CAL10N when using the custom converters for localizing level names. I also used this idea to implement a custom converter that localize the string "Caller+". Running my application using this new converter I obtain the same performances in term of execution time I get using logback with modified Level and CallerDataConverter classes. Cheers, Dario

2 1

Logback with Tomcat 7
by martin.burchard＠pentos.com 05 Jun '12

05 Jun '12

Hello, today I've changed the WAR file of my App to only contain the classes of my project. All other dependencies , also logback, I put into the tomcat/lib folder. The logback.xml is still in my WAR, but it looks like it is now ignored. Then I put the logback.xml also into the lib folder and changed it, that it configures only the root logger. Seems to work, but my logback.xml in the WAR file is still ignored. How can a set up a global logging and in addition configure logging on a per webapp basis? Regards Martin

2 1

Re: [logback-user] Localized log level names
by Dario Campagna 04 Jun '12

04 Jun '12

Hi all, Just an update on the statistics regarding the generation of logging event with localized level names. I forgot to mention that the statistics I reported in my previous mail were related to the generation of logging event in which also the string "Caller+" (generated by the conversion word caller) and messages were localized, not only the level names. To localize the string "Caller+" I tried both an approach based on Ceki idea (i.e., I implemented a customized CallerDataConverter), and an approach based on the modification of the class CallerDataConverter. To localize log messages I followed the instructions reported at http://www.slf4j.org/localization.html. Today I made a little modification to my version of CallerDataConverter. Now my application on an input that leads to the generation of about 63000 logging events runs in about 28 seconds (instead of 46) using my modified version of logback-classic. The number of invocations of MakePropertyResourceBoundle is 14 (instead of 266). Hence, the internationalization of level names and the string "Caller+" obtained modifying logbcak-classic classes seems to be more efficient than the internationalization based on custom converters for new conversion words. This due to the reduced number of invocations of the method MakePropertyResourceBoundle of CAL10N. Dario

1 0

Re: [logback-user] Localized log level names
by Dario Campagna 01 Jun '12

01 Jun '12

Hi Ceki, > Have you considered customizing LevelConverter [1] ? I followed your suggestions and implemented with success a customized LevelConverter. This solution for level names internationalization is of course less invasive than the one I devised (that consists in modifying the Level class). However, the use of the new conversion word for obtaining localized level names leads to higher computation time in the application I am working on. For example, running the application on an input that leads to the generation of about 63000 logging event, when using the conversion word level in patterns (1) the execution takes about 22 seconds, while when using the new conversion word for localized level names (2) takes about 66 seconds. Using the solution I devised (3) the application takes 46 seconds to terminate. The main difference I noticed between the three executions is the number of invocations to the method makePropertyResourceBoundle of the class CAL10NResourceBoundleFinder. For (1) that method is invoked about 500 times, and the execution times of these invocation sum up to about 34 seconds. For (2) we have about 19 invocations for a total of 299 ms. For (3) about 266 invocations for a total of 18 seconds. I still have to see what exactly that method does, however I find this differences in the number of invocations a bit strange. Cheers, Dario

1 0

Release of logback version 1.0.4
by ceki 01 Jun '12

01 Jun '12

Hello all, I am thrilled to announce the release of logback version 1.0.4. It should hit the Maven central repository within the next 24 hours. Please refer to the news page for precise details of this release. http://logback.qos.ch/news.html You can download logback, including full source code, class files and documentation on our download page, shown below. http://logback.qos.ch/download.html You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki http://twitter.com/#!/ceki

2 1