- logback-user - mailman3.qos.ch

Getting null from getPropertyMap in LogbackMDCAdapter in the same thread, different binary
by GS 04 Aug '11

04 Aug '11

After switching from log4j to logback, I am getting null from getPropertyMap() in LogbackMDCAdapter. I can confirm that it's the same thread where the value is being put. However the put is called in a different binary (same JVM of course). If logging is done in the same codebase (binary) where MDC put is called, it works as expected bug it the logger is invoked from a different binary, copyOnInheritThreadLocal.get() in getPropertyMap() is returning null. Any suggestions? Thanks!

3 5

Choosing the right triggering and rolling policy
by manoj mathai 01 Aug '11

01 Aug '11

Hi, I am new to logback. I am trying to configure the time and rolling policy for a rolling file appender. Here's what I need: a) Every "x" minutes, I want it to roll the file regardless of how small the size of the live file is.(low logging rate) b) If within those "x" minutes, the live log file size exceeds "y" KBs, i want it to use indices like ${date_time}.0.log and ${date_time}.1.log and so on. ( high logging rate) I'd like "x" to be 15 mins, but if that's not doable, I can live with "x = 1 minute". Here's my config, which doesn't seem to do exactly what I've described: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${user.home}/impression_logs/impressions.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${user.home}/impression_log_archives/${HOSTNAME}/impressions.%d{yyyy-MM-dd-hh-mm}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>1MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <encoder> <pattern>%msg%n</pattern> </encoder> </appender> Can some one help me with this ? -- Manoj M

1 0

How to log to different files from different classes?
by Mark Kerzner 27 Jul '11

27 Jul '11

Hi, I want to log profiler information to one log, and regular debug information to different one. How would one do that? Thank you, Mark

1 0

Re: [logback-user] Problem with Logback.XML
by BAKHTI Mohammed 25 Jul '11

25 Jul '11

Thanks I have already think about something like this but it's not really nice, (if in the future i need to change smething i have to make changes in java files) No one know about how to "exclude component from the default configuration" or "multi-step configuration" as slf4j doccumentation said ? In slf4j they said : The only way to obtain output from the listed loggers, is to isolate the components invoking these loggers and to exclude them from the default configuration. Both logback and log4j allow multi-step configuration. It follows that the problematic components should be configured in a second step separate from default configuration. To: onlymed(a)hotmail.com; logback-user(a)qos.ch From: djt69(a)comcast.net Subject: Re: [logback-user] Problem with Logback.XML Date: Mon, 4 Jul 2011 11:08:05 -0400 The way I got around it with my filter was to create another class with a static method that the filter called. The other class had a logger instantiated and took care of the logging for the filter. Sent from my Verizon Wireless Phone ----- Reply message ----- From: "BAKHTI Mohammed" <onlymed(a)hotmail.com> Date: Mon, Jul 4, 2011 9:47 am Subject: [logback-user] Problem with Logback.XML To: <djt69(a)comcast.net>, <logback-user(a)qos.ch> Thanks for the replay : so how can i deal with this ? In slf4j they said : The only way to obtain output from the listed loggers, is to isolate the components invoking these loggers and to exclude them from the default configuration. Both logback and log4j allow multi-step configuration. It follows that the problematic components should be configured in a second step separate from default configuration. But i don't figure how ? what really i need to do. Thansk again for any help To: onlymed(a)hotmail.com; logback-user(a)qos.ch From: djt69(a)comcast.net Subject: Re: [logback-user] Problème with Logback.XML Date: Mon, 4 Jul 2011 08:52:24 -0400 If you instantiate a logger in a filter class you'll have the same problem. The message is telling you that you can't use a logger in part of Logback's init. Sent from my Verizon Wireless Phone ----- Reply message ----- From: "BAKHTI Mohammed" <onlymed(a)hotmail.com> Date: Mon, Jul 4, 2011 3:31 am Subject: [logback-user] Problème with Logback.XML To: <logback-user(a)qos.ch> Hello, I just made an API abstraction above logback in order to add specific functions in this api i have all logback functions (juste overrided with no changes) and add some other functions (with specific signature) : I created then a file appender and a JMS appender in logback.xml (nothing special) I am using activemq for jms MOM. The problem is then : when a run a test class with some methodes invocation i see this message : SLF4J: The following loggers will not work becasue they were created SLF4J: during the default configuration phase of the underlying logging system. SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger SLF4J: org.apache.activemq.ActiveMQPrefetchPolicy SLF4J: org.apache.activemq.jndi.ReadOnlyContext SLF4J: org.apache.activemq.transport.tcp.TcpTransportFactory SLF4J: org.apache.activemq.util.ServiceSupport All user logs are logged as expected but i dont see any of activemq (or other framework) logs . i have read the information in slf4j url but don't understund what they mean and how to correct this problem in logback . Thanks for any help

2 3

Resource [file:logback.xml] occurs multiple times on the classpath
by Jason Berk 25 Jul '11

25 Jul '11

new user here....making the jump for log4j to logback. Running an executable jar where logback.xml is NOT in the jar. Application works as expected, but I'm seeing all these "Resource [file:logback.xml] occurs at [file:logback.xml]" in the log. jberk@ubuntu:~/apps$ java -Dlogback.configurationFile=file:logback.xml -Dapp.props=file:app.props \ -Dinput.file=test.txt -Doutput.dir=pdf -jar MyJar.jar mortgage 13:01:09,754 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [file:logback.xml] at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs multiple times on the classpath. 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,756 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,757 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [file:logback.xml] occurs at [file:logback.xml] 13:01:09,830 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 13:01:09,835 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 13:01:09,839 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT] 13:01:09,866 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 13:01:09,914 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework] to OFF 13:01:09,914 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.apache] to OFF 13:01:09,914 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG 13:01:09,914 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] ....my app logs omitted..... here is my logback.xml: <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d %-5level %C[%M%L] - %msg%n</pattern> </encoder> </appender>  <logger name="org.springframework" level="OFF"/> <logger name="org.apache" level="OFF"/> <root level="debug"> <appender-ref ref="STDOUT"/> </root> </configuration> 1) why is this happening? 2) is this something I am doing wrong (and how to fix) thanks for the great tool and any help. Jason

3 5

ch.qos.logback.access.tomcat.LogbackValve overrides final method start
by Seidler.EDV 24 Jul '11

24 Jul '11

Hello, I tried to configure logback for tomcat 7.0.29 according to the instructions in "HTTP-access logs with logback-access, Jetty and Tomcat". But now I get an exception when I want to start tomcat that states ch.qos.logback.access.tomcat.LogbackValve overrides final method start. Is logback not compatible with tomcat 7? Regards Bernd

1 0

how to redirect system.out/err to a file?
by Zhangguangchao 22 Jul '11

22 Jul '11

Hi, Is there a configuration to redirect STDOUT to a file? By the way, I found the same question asked in http://www.qos.ch/pipermail/logback-user/2009-June/001141.html and I wanna know whether it is fixed and how. And I didn't found the new feature about ConsoleAppender configuration changed in Logback News. Thanks a lot. Dominic Zhang

3 4

A new ReconfigureOnChangeFilter at each reload of the config file
by dunand 20 Jul '11

20 Jul '11

I started playing with Logback yesterday. I use scan="true" because I want an easy way to modify logging without redeploying my webapp. I noticed that each time I modify logback.xml a new ReconfigureOnChangeFilter is created. After 4 modifications and reloading of logback.xml the logback is reloaded 4 times because each new ReconfigureOnChangeFilter scan and reload the config file. Also, the logging work correctly. My message are logged one time (not 5 times). My only concern is that a new ReconfigureOnChangeFilter is created every time the config file is reloaded. What I'm I doing wrong ? The output from debug="true". I made 4 modifications in the config file. 1 modif : changed level of com.lq from DEBUG to WARN 2 modif : changed scan time from 7 to 8 seconds 3 modif : changed scan time from 8 to 9 seconds 4 modif : changed scan time from 9 to 10 seconds http://old.nabble.com/file/p32099960/logback-debug-2.log logback-debug-2.log My logback.xml : <configuration scan="true" scanPeriod="30 seconds" debug="true"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <root level="debug"> <appender-ref ref="STDOUT" /> </root> </configuration> I use a ServletContextListener to initialize Logback because I want a way to change the logging configuration without redeploying my webapp. If you have a better way, I'm open to suggestion : public void contextInitialized(ServletContextEvent sce) { LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); // the context was probably already configured by default configuration rules lc.reset(); ServletContext servletContext = sce.getServletContext(); configurator.doConfigure(servletContext.getInitParameter(LOGBACK_CONFIG_FILE_PARAMETER)); } catch (JoranException je) { // StatusPrinter will handle this } } -- View this message in context: http://old.nabble.com/A-new-ReconfigureOnChangeFilter-at-each-reload-of-the… Sent from the Logback User mailing list archive at Nabble.com.

2 5

RollingFileAppender don't roll at all
by Sakho Meissa 14 Jul '11

14 Jul '11

Hi all, I'm tearing my hairs off to understand why the RollingFileAppender in my configuration doesn't behave as expected. I'm using logBack 0.9.15 version with jboss 5.1 EAP. My configuration file is below with few remarks: 1) The fileNamePattern I've set (in bold) is supposed to create a new file file each minute. 2) I've set layout instead of an encoder (which is in pattern) because encoder in not supported in this version of logback. When I start the server the output seem to be ok with my configuration and a log file named tpm-ws.log is created as expected. After one day of testing, there is no other file created. All logs are still generated in the same file. Can someone explain me what's wrong in my configuration? Is the RollingFileAppender supported in the 0.9.15 version. <configuration debug="true" scan="true"> <property name="tpm-log-file" value="C:\\Developpement\\jboss\\jboss-5.1.0.GA\\server\\default\\conf\\confwspatio\\logs\\tpm-ws.log" /> <appender name="TPM-WS-LOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${tpm-log-file}</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>logFile.%d{yyyy-MM-dd-HHmm}.log</fileNamePattern>  <maxHistory>30</maxHistory> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>1MB</maxFileSize> </triggeringPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{dd/MM/yyyy HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</Pattern> </layout>  </appender> <root level="TRACE"> <appender-ref ref="TPM-WS-LOG" /> </root> <logger name="org.springframework" level="TRACE"> <appender-ref ref="TPM-WS-LOG" /> </logger> </configuration> Thanks in advance. Meissa SAKHO NATIXIS Systémes d'information Achats et Logistique / Etudes -Banque Privée Tél. : +33 1 58 32 20 88 : +33 6 01 27 58 46 www.natixis.com<http://www.natixis.com> L'integrite de ce message n'etant pas assuree sur internet, Natixis ne peut etre tenu responsable de son contenu. Toute utilisation ou diffusion non autorisee est interdite. Si vous n'etes pas destinataire de ce message, merci de le detruire et d'avertir l'expediteur. Ensemble, faisons un geste pour l'environnement : n'imprimons nos mails que si necessaire. The integrity of this message cannot be guaranteed on the Internet. Natixis can not therefore be considered responsible for the contents. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender. Let us mind the environment : let's print our mails only when necessary

2 1

logback and thread safety?
by Boyer, Brent B 11 Jul '11

11 Jul '11

Does anyone know of where the documentation is concerning lobagback and thread safety? Logback, particularly high level "user facing" classes like Logger, has to be multithread safe, right? I cannot imagine otherwise, but I there seems to be no thorough discussion of its thread safety. On the logback website, the sole discussion I found was this brief mention in the manual: "All appenders shipped with the logback distribution extend the AppenderBase abstract class that implements the doAppend method in a synchronized block ensuring thread-safety." http://logback.qos.ch/manual/architecture.html I also found this 4 year old posting to this email list http://old.nabble.com/logback-and-concurrency-to10189585.html#a10311135 in which no less than Ceki Gülcü says that logback is thread safe. But he gives no details. Every single logback class javadoc that I looked at is silent about MT safety. (Indeed, there seem to be minimal javadocs about anything. It ought to be a requirement that every single class committed to source control includes in its class javadoc a comment about thread safety.) A web search found one person claiming a bug (in slf4j) here: http://neopatel.blogspot.com/2010/12/slf4j-over-sysout-not-thread-safe.html If anyone knows where this is discussed more thoroughly, please share the link(s). Also, if this question is more appropriate for the dev list, let me know and I will do that. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

2 2