- logback-user - mailman3.qos.ch

use property substitution for login credential in logback.xml from tomcat context.xml
by stephen.t.chan＠asia.bnpparibas.com 07 Jun '12

07 Jun '12

Hi all, I am running tomcat6 as http server and specify jdbc connection(with login credential) in context.xml. Besides, I have defined to use DBAppender in logback.xml to write log to database. My question is, instead of directly write the login credential in the logback.xml file, how to use property substitution to retrieve the credential from tomcat context.xml? for example, <appender name="DB" class="com.eqd.iprice.appender.DBAppender"> <connectionSource class= "ch.qos.logback.core.db.DriverManagerConnectionSource"> <dataSource class="javax.sql.DataSource"> <driverClass>${driverClass}</driverClass> <url>${url}</url> <user>${username}</user> <password>${password}</password> </dataSource> </connectionSource> </appender> Those ${XXXX} are retrieved from tomcat context.xml . Thanks. Stephen This message and any attachments (the "message") is intended solely for the intended addressees and is confidential. If you receive this message in error,or are not the intended recipient(s), please delete it and any copies from your systems and immediately notify the sender. Any unauthorized view, use that does not comply with its purpose, dissemination or disclosure, either whole or partial, is prohibited. Since the internet cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS (and its subsidiaries) shall not be liable for the message if modified, changed or falsified. Do not print this message unless it is necessary,consider the environment. ------------------------------------------------------------------------------------------ Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur ou s'il ne vous est pas destine, merci de le detruire ainsi que toute copie de votre systeme et d'en avertir immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de ce message qui n'est pas conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer l'integrite de ce message electronique susceptible d'alteration, BNP Paribas (et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese ou il aurait ete modifie, deforme ou falsifie. N'imprimez ce message que si necessaire, pensez a l'environnement.

2 1

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

Replacing JUL with logback with Tomcat
by Alex Glass 31 May '12

31 May '12

I have setup logback-access according to the documentation with a LogbackValve and my Tomcat instance is logging requests. However it seems Tomcat is still writing messages to the console using JUL. What is the best way to route these messages to logback? Do I configure Tomcat to use log4j and then try and bridge those messages into logback-classic or is there a less complicated way? In the past I followed these instructions [1] to get Tomcat logging with log4j but would rather just use logback going forward. Thanks, Alex http://mrhaki.blogspot.com/2011/02/configure-log4j-on-tomcat.html

4 9

Log Filtering base on issuing class (%C)
by Gonzalo Vasquez 30 May '12

30 May '12

I can't seem to find out how to filter my logs bases on the class name that issued the logged statement. Is any of of the pre-shipped filters suitable for this task? Regards, Gonzalo Vásquez Sáez Gerente Investigación y Desarrollo (R&D) Altiuz Soluciones Tecnológicas de Negocios Ltda. Av. Nueva Tajamar 555 Of. 802, Las Condes (56-2) 335 2461 gvasquez(a)altiuz.cl http://www.altiuz.cl

2 9