- logback-user - mailman3.qos.ch

log4j to logback translation issues - $ char in logger name, and rolling policy
by Stevo Slavić 04 Mar '16

04 Mar '16

Hello Logback community, I converted Apache Kafka log4j.properties to logback.xml using http://logback.qos.ch/translator/ Translator didn't report invalid '$' char in logger name, only when running app, logback threw exception: 16:07:38,628 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@701:80 - RuntimeException in Action for tag [logger] java.lang.IllegalArgumentException: Failed to parse input [kafka.network.RequestChannel$] at java.lang.IllegalArgumentException: Failed to parse input [kafka.network.RequestChannel$] at at ch.qos.logback.core.util.OptionHelper.substVars(OptionHelper.java:114) at at ch.qos.logback.core.joran.spi.InterpretationContext.subst(InterpretationContext.java:157) at at ch.qos.logback.classic.joran.action.LoggerAction.begin(LoggerAction.java:44) at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:269) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:148) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:100) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:50) at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75) at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:147) at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:122) at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:378) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:328) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:349) at at org.apache.kafka.common.utils.Utils.<clinit>(Utils.java:54) at at kafka.Kafka$.getPropsFromArgs(Kafka.scala:41) at at kafka.Kafka$.main(Kafka.scala:57) at at kafka.Kafka.main(Kafka.scala) Caused by: ch.qos.logback.core.spi.ScanException: Unexpected end of pattern string at at ch.qos.logback.core.subst.Tokenizer.tokenize(Tokenizer.java:70) at at ch.qos.logback.core.subst.NodeToStringTransformer.tokenizeAndParseString(NodeToStringTransformer.java:53) at at ch.qos.logback.core.subst.NodeToStringTransformer.substituteVariable(NodeToStringTransformer.java:46) at at ch.qos.logback.core.util.OptionHelper.substVars(OptionHelper.java:112) at ... 23 common frames omitted Should $ char be allowed in logger name? In other words is it bug in configuration if one uses it or is it bug in logback that it doesn't handle it well? I'm using logback 1.7.18. Secondly, translator had problems converting data pattern like: log4j.appender.kafkaAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.kafkaAppender.DatePattern='.'yyyy-MM-dd-HH log4j.appender.kafkaAppender.File=${kafka.logs.dir}/server.log it converted that to ... <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${kafka.logs.dir}/server.log.%d{'.'yyyy-MM-dd-HH}</fileNamePattern> </rollingPolicy> ... where Logback complained about that dot '.' in fileNamePattern as invalid. Lastly, it seems in Logback specification when to roll (e.g. daily) and what should be format and info included in the file name are tightly coupled. Kind regards, Stevo Slavic.

2 2

logback and flume
by Mike Lewis 02 Mar '16

02 Mar '16

Hi, I was just wondering if anyone had experience using logback with flume? If so, Could you let me know the particular libs you used, I’ve tried a few things with no success. Regards, Mike Lewis -------------------------------------------------------------------------------------------------------------------------- This email has been sent to you on behalf of Nephila Advisors LLC (“Advisors”). Advisors provides consultancy services to Nephila Capital Ltd. (“Capital”), an investment advisor managed and carrying on business in Bermuda. Advisors and its employees do not act as agents for Capital or the funds it advises and do not have the authority to bind Capital or such funds to any transaction or agreement. The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. Any use, disclosure, reproduction, modification or distribution of the contents of this e-mail, or any part thereof, other than by the intended recipient, is strictly prohibited. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. This email is for information purposes only, nothing contained herein constitutes an offer to sell or buy securities, as such an offer may only be made from a properly authorized offering document. Although Nephila attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------- This email has been sent to you on behalf of Nephila Advisors UK (“Advisors UK”). Advisors UK provides consultancy services to Nephila Capital Ltd. (“Capital”), an investment advisor managed and carrying on business in Bermuda. Advisors UK and its employees do not act as agents for Capital or the funds it advises and do not have the authority to bind Capital or such funds to any transaction or agreement. The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. Any use, disclosure, reproduction, modification or distribution of the contents of this e-mail, or any part thereof, other than by the intended recipient, is strictly prohibited. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. This email is for information purposes only, nothing contained herein constitutes an offer to sell or buy securities, as such an offer may only be made from a properly authorized offering document. Although Nephila attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. --------------------------------------------------------------------------------------------------------------------------

3 5

More information about log back mechanism and configuration
by Roberto Pecoraro 29 Feb '16

29 Feb '16

Hi team, I would like to reduce kairosdb traces in log files, then i need to change the configuration in order to have limited log size and wrap around log files. This is my current log configuration file: <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level [%file:%line] - %msg%n</pattern> </encoder> </appender> <appender name="logfile" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>log/kairosdb.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>log/kairosdb.%d{yyyy-MM-dd}.log</fileNamePattern>  <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{MM-dd|HH:mm:ss.SSS} [%thread] %-5level [%file:%line] - %msg%n</pattern> </encoder> </appender> <logger name="com.mchange.v2.c3p0" level="WARN"/> <root level="DEBUG"> <appender-ref ref="stdout"/> <appender-ref ref="logfile"/> </root> </configuration> My requirement is to have 'N' files of maximum size 'S' MB which go in rollover, possibly leaving the first file unchanged. Thanks and regards Ciao Roberto.

2 1

Release of logback version 1.1.6
by Ceki Gulcu 29 Feb '16

29 Feb '16

Hello all, The logback team is happy to announce the release of logback version 1.1.6. It contains important bug fixes and improvements. It should hit the Maven central repository by the time you read this message. Here some notable changes that you should be aware of. * Logback now *requires* SLF4J version 1.7.16 or later. * MDC values are no longer inherited by child threads. * Packaging data (as output in stack traces) is now disabled by default. Please refer to the news page for precise details. http://logback.qos.ch/news.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 You may also receive announcements via twitter by following: https://twitter.com/qos_ch Enjoy, -- Ceki

1 0

JMXConfigurator problem with IBM WebSphere
by Dale.Chapman＠medavie.bluecross.ca 24 Feb '16

24 Feb '16

Hi Folks. I have looked through the archives looking for an answer on what to do to get the JMXConfigurator working with WebSphere. The last entry I was able to see was from Ceki on Jun 12, 2012. Has anyone done any further research into this? If not, this is what I have found. I have spent some time trying to understand the problem. What I have been able to figure out is how to configure WebSphere to show the Logback JMX MBean in an "unsupported" mode using the platform MBean server. found here ( https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.jazz.repository… ) Essentially, you need to configure websphere with the following JVM arguments: -Dcom.ibm.team.server.monitoring.mbean.server=WebSphere -Djavax.management.builder.initial= -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false Once I did this, I was able to get jconsole to allow me to manage Logback within WebSphere. I would prefer to be able to use jconsole in the supported JSR160RMI connector mode. This involves configuring websphere with the following JVM argument: -Dcom.ibm.team.server.monitoring.mbean.server=WebSphere and then configuring jconsole with the information contained in the same article in the Option 2: Setting up JMX in JSR160RMI connector section. When I configured WebSphere and jconsole in this fashion, I was able to connect to an MBean server, but it did not include the Logback bean. With the help of a couple of coworkers, we were able to find the following documentation: https://www-01.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websphe… which indicates that WebSphere expects that the MBean be registered as follows: MBeanFactory mbfactory = AdminServiceFactory.getMBeanFactory(); mbfactory.activateMBean("SnoopMBean", snoop, "snoopMBeanId", "SnoopMBean.xml"); The code I downloaded from git for Logback shows that the JMXConfigurator uses the following: MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); mbs.registerMBean(jmxConfigurator, objectName); I was thinking that an appropriate solution to the WebSphere problem might be to add a JVM config flag such as org.qos.logback.websphere and if the flag is set to true, the begin() method of the JMXConfiguratorAction class could follow the expected IBM MBean registration instead of the standard. Opinions? Dale Chapman, Architect - MAAX Support Medavie 506-867-4430 dale.chapman@medavie.bluecross.ca----------------------------------------------------------------------- This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal, and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply. Thank you. La présente communication, y compris toute pièce qui y a été jointe, est destinée uniquement à la personne ou à l’entité à laquelle elle a été adressée, et contient des renseignements à caractère confidentiel et personnel. Toute diffusion ou reproduction non autorisée ou toute intervention entreprise relativement à son contenu est strictement interdite. Si vous avez reçu ce message par erreur, veuillez nous le signaler immédiatement afin que nous puissions effectuer la correction à nos dossiers. Veuillez par la suite supprimer ou détruire le contenu de la transmission originale ainsi que toute réponse ultérieure. Merci. -----------------------------------------------------------------------

1 0

Rolling file appender not working for portal.log in /portal
by David Brown 23 Feb '16

23 Feb '16

Howdy, I looked at the archived email but no way to search. I am using logback in uportal on two different machines both running the uportal server @localhost. The one machine is using a fresh clone of uportal. The other machine is my dev box for the company implementation of uportal. My machine logback is working as expected with the file rolling appender. The company dev box is issuing diskspace warnings because portal.log is growing unbounded. There are no .gz files in the /portal directory which leads me to believe the rolling file appender is not working. Inspection of logback.xml provides no clues as to what is wrong. Any diagnostics or suggestions welcomed. Kindly regards.

2 1

how to deactivate logger (OFF) in the threads. The messages are still displayed in the console
by Sky Dog 23 Feb '16

23 Feb '16

Hi all, I am using a small logback.xml conf file to display the logger messages into the console ---------------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>OFF</level> </filter> <encoder> <pattern>%d{HH:mm:ss.SSS} %-5level %logger{25} - %msg%n</pattern> </encoder> </appender> <root level="INFO"> <appender-ref ref="STDOUT"/> </root> <logger level="ERROR" name="general"/> <logger level="OFF" name="net"/> <logger level="OFF" name="wire"/> <logger level="OFF" name="VM"/> <logger level="OFF" name="dump"/> <logger level="OFF" name="gas"/> <logger level="INFO" name="sync"/> <logger level="INFO" name="blockqueue"/> </configuration> ---------------------------------------------------------------------------- The problem is, I still see the *VM* and *gas* messages from the logger although I have deactivated it (OFF): 2016-02-22 21:36:13.389 INFO 7574 --- [ Thread-10] *gas* : [369500479] Spent for cause: [DUP1], gas: [3] 2016-02-22 21:36:13.389 INFO 7574 --- [ Thread-10] *VM* : [278] Op: [DUP1 ] Gas: [478018] Deep: [0] Hint: [] 2016-02-22 21:36:13.389 INFO 7574 --- [ Thread-10] *gas* : [369500479] Spent for cause: [PUSH4], gas: [3] 2016-02-22 21:36:13.390 INFO 7574 --- [ Thread-10] *VM* : [283] Op: [PUSH4 ] Gas: [478015] Deep: [0] Hint: [abc00bb4] 2016-02-22 21:36:13.390 INFO 7574 --- [ Thread-10] *gas* : [369500479] Spent for cause: [EQ], gas: [3] The classes which uses the logger, they define it as follows: private static final Logger logger = LoggerFactory.getLogger("VM"); private static final Logger dumpLogger = LoggerFactory.getLogger("dump"); What am I missing? I want to avoid the *VM* and *gas* messages Regards and thanks in advance! S.

2 1

logging stopped, using AsyncAppender and SocketAppender
by Tara Czutno 15 Feb '16

15 Feb '16

I have 3 servers with various java process, I want all processes to write to one log on machineA. I am doing a load test with a lot of logging, but it appears logging from the main process has stopped. Is there a way to check for logback status? Is the setup below the correct way to go about having one log? I set this up so SimpleSocketServer is running with this config: <configuration scan="true" scanPeriod="60 seconds"> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/opt/twc/logs/ecp.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/opt/twc/logs/ecp.log.%d{yyyy-MM-dd}</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{ISO8601} %-14mdc{application} %-5level [%t] %logger{100} - %msg%n %xEx</pattern> <immediateFlush>false</immediateFlush> </encoder> </appender> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>100000</queueSize> <discardingThreshold>0</discardingThreshold> <includeCallerData>true</includeCallerData> <maxFlushTime>5000</maxFlushTime> <appender-ref ref="FILE"/> </appender> <root level="DEBUG"> <appender-ref ref="ASYNC"/> </root> </configuration> All other processes are running with this config: <configuration> <appender name="SOCKET" class="ch.qos.logback.classic.net.SocketAppender"> <remoteHost>ecplogger</remoteHost> <port>6000</port> <reconnectionDelay>5 seconds</reconnectionDelay> <includeCallerData>true</includeCallerData> <queueSize>100000</queueSize> <eventDelayLimit>100 milliseconds</eventDelayLimit> </appender> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>100000</queueSize> <discardingThreshold>0</discardingThreshold> <includeCallerData>true</includeCallerData> <maxFlushTime>5000</maxFlushTime> <appender-ref ref="SOCKET"/> </appender> <root level="ALL"> <appender-ref ref="ASYNC"/> </root> </configuration>

1 1

Log file ot created
by Paolo Di Tommaso 14 Feb '16

14 Feb '16

Hi, After upgrading from Logback 1.1.3 to version 1.1.5 I've noticed that it isn't creating the log file any more. I'm using a RollingFileAppender configured using a piece of code like this: RollingFileAppender result = logFileName ? new RollingFileAppender() : null result.file = logFileName def rollingPolicy = new FixedWindowRollingPolicy( ) rollingPolicy.fileNamePattern = "${logFileName}.%i" rollingPolicy.setContext(loggerContext) rollingPolicy.setParent(result) rollingPolicy.setMinIndex(1) rollingPolicy.setMaxIndex(9) rollingPolicy.start() result.rollingPolicy = rollingPolicy result.encoder = createEncoder() result.setContext(loggerContext) result.setTriggeringPolicy(new RollOnStartupPolicy()) result.start() Something has changed that logic ? Cheers, Paolo

2 4

MDC.clear() invoked in child class deletes parent keys
by Kuu 10 Feb '16

10 Feb '16

Hello, I found an issue using the MDC. I have a filter that does the following: .... MDC.put("key", value); filterChain.doFilter(request, response); value = MDC.get("key"); ... And the value is empty. The problem comes because a child controller class does: MDC.put("key2") ... some logic.... finally{ MDC.clear(); } And that call deletes all the content of the map. The problem is that the child class does not check if the MDC contains something. Of course this could be considered as a bad practice, but this "clear()" method is too risky as it deletes ALL, even the parent keys... I found this ticket : http://jira.qos.ch/browse/LOGBACK-325 <http://www.google.com/url?q=http%3A%2F%2Fjira.qos.ch%2Fbrowse%2FLOGBACK-325…> but it seems to be resolved. The version I'm using is the loback-classic 1.1.2 Let me know if you need more information. Thank you. Best Regards, Javier

3 2