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

Help: DatedFileAppender
by Ajaykumar Ashokkumar Lavhade 19 Jun '13

19 Jun '13

Dear Team, We are thinking to migrate Log4j to Logback. In Log4j we have used appender as a DatedFileAppender. So, that there is no need for rolling. Please let me know if Logback supports DatedFileAppender? If not then is there any alternative for it? Many thanks, Ajay **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***

1 0

Fwd: [slf4j-user] How to get the filename used by an appender
by Ulrich 17 Jun '13

17 Jun '13

So I will ask my question here: Is it possible to get known the name of the file used for logging? Ulrich Anfang der weitergeleiteten E‑Mail: > Von: Ulrich <Forums(a)gombers.de> > Datum: 17. Juni 2013 21:31:58 MESZ > An: User list for the slf4j project <slf4j-user(a)qos.ch> > Betreff: Re: [slf4j-user] How to get the filename used by an appender > Antwort an: User list for the slf4j project <slf4j-user(a)qos.ch> > > To be honest, I don't know how the Logger-Implementation intercepts SLF4J. But referring to a special logger from an application is a contradiction of the idea behind SLF4J. From my point of view there should be a programmatical opportunity to get hold of the logs. > Butbthank you anyway - I will ask my question to the logback mailing list. > > Am 17.06.2013 um 17:43 schrieb Ceki Gülcü <ceki(a)qos.ch>: > >> >> In that case, please post your question on the logback-user mailing list. >> >> On 6/17/2013 5:41 PM, Ulrich wrote: >>> I'm using logback. >>> >>> Am 17.06.2013 um 14:16 schrieb Ceki Gülcü <ceki(a)qos.ch>: >>> >>>> >>>> Which logging framework are you using? SLF4J does not have a notion of appenders... >>>> >>>> On 6/17/2013 2:01 PM, Ulrich wrote: >>>>> Is it possible to get the filename/resource used by an appender? >>>>> Ulrich >>>>> _______________________________________________ >>>>> slf4j-user mailing list >>>>> slf4j-user(a)qos.ch >>>>> http://mailman.qos.ch/mailman/listinfo/slf4j-user >>>> _______________________________________________ >>>> slf4j-user mailing list >>>> slf4j-user(a)qos.ch >>>> http://mailman.qos.ch/mailman/listinfo/slf4j-user >>> _______________________________________________ >>> slf4j-user mailing list >>> slf4j-user(a)qos.ch >>> http://mailman.qos.ch/mailman/listinfo/slf4j-user >> _______________________________________________ >> slf4j-user mailing list >> slf4j-user(a)qos.ch >> http://mailman.qos.ch/mailman/listinfo/slf4j-user > _______________________________________________ > slf4j-user mailing list > slf4j-user(a)qos.ch > http://mailman.qos.ch/mailman/listinfo/slf4j-user

1 0

debug output when using Groovy configuration
by sw＠stinemail.com 17 Jun '13

17 Jun '13

Hi, Thank you for logback and slf4j. We have found them very useful. I would like to inquire about debugging output, starting with the intended behavior of the system property logback.debug. It appears to have no effect if an application is configured via Groovy. Setting logback.statusListenerClass does have some effect, though the output is not as verbose as with XML configuration. I created a sample project that demonstrates the differences: https://github.com/dstine/logback-debug-groovy. My experiments use the latest released version of logback 1.0.12. My first question is, should logback.debug behave the same for both XML and Groovy configuration? If yes, my next question is, how would we fix this? I see the following code in ConfigurationAction (XML): https://github.com/qos-ch/logback/blob/71886409e62533af0bdf1d922a7d66f3818d… It looks like logback.debug is simply a shortcut for adding the status listener. Is that correct, or is there anything else at play? Should we "just" copy this code to ConfigurationDelegate (Groovy), or centralize it somehow? Next, the output for Groovy config appears to not include information about configuring loggers, whereas XML config provides this output: 11:43:58,046 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 11:43:58,078 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG 11:43:58,078 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] Last, are there other differences I have not yet noticed? Thanks, Dan

3 3

SyslogAppender behaving strangely
by Robert Kuhar 14 Jun '13

14 Jun '13

My SyslogAppender succeeds in sending messages to the syslogd on my MacBook, but the messages themselves are "corrupt" the syslogd logs them. For example, a RollingFileAppender <appender name="DAILY_ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>logs/dm.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>logs/dm.%d{yyyyMMdd}.log</FileNamePattern> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd'T'HH:mm:ss.SSS} [%p] %c{2} DSN:%X{X-HTC-DEVICE-SN} APV:%X{X-HTC-APP-VERSION} RID:%X{X-HTC-REQUEST-ID} - %m%n</pattern> </encoder> </appender> logs a message like... 2013-06-06T15:02:17.129 [INFO] Global$ DSN: APV: RID: - dm2-server starting But the SysLog appender dorks the message corrupting the %d timestamp and duplicating the level. My SyslogAppender is configured like... <appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender"> <syslogHost>localhost</syslogHost> <facility>local4</facility> <suffixPattern>%d{yyyy-MM-dd'T'HH:mm:ss.SSS} %p %c{2} DSN:%X{X-HTC-DEVICE-SN} APV:%X{X-HTC-APP-VERSION} RID:%X{X-HTC-REQUEST-ID} - %m</suffixPattern> </appender> With the same log message appearing like... Jun 6 15:02:17 bobk-mbp.local 2013-06-06T15 <Info>: 02:17.129 INFO Global$ DSN: APV: RID: - dm2-server starting Where did the <Info> come from and what is it doing in the middle of logback's %d timestamp? Is this logback messing up or syslogd? Any recommendations on how to troubleshoot this? Bob

2 5

Re: [logback-user] Shutting down async appenders, when using logback through slf4j
by Mads Bondo Dydensborg 14 Jun '13

14 Jun '13

(Moved to list for the benefit of google) Torsdag 13 juni 2013 17:54:58 skrev Ceki Gülcü: > > On 6/13/2013 5:17 PM, Mads Bondo Dydensborg wrote: > > Thank you! > > > > But .. that anchor does not appear to be present in the text? > > It takes 30 minutes for changes on the master server to propagate to the > slaves. Please try again. Thanks, it is there now. > > > Also, can this be done from the config file? Because the app only knows slf4j ... :-/ > > How can the config file know when to shutdown logback? Only code invoked > at application redeploy, such as > ServletContextListener.contextDestroyed(), can shutdown logback. What do I know - perhaps it was possibly to do some magic there ;-) I have inserted this code in the contextDestroyed method: if ( LoggerFactory.getILoggerFactory() instanceof LoggerContext ) { ((LoggerContext) LoggerFactory.getILoggerFactory() ).stop(); } I guess I was not aware that the getILoggerFactory would return such code. Now I just hope that it is still possibly to use this with Log4j or other slf4j compatible frameworks. Thanks a lot. Mads > > > > > Mvh > > > > Mads > > > > Torsdag 13 juni 2013 16:42:19 skrev Ceki Gülcü: > >> You need to shutdown logback when redeploying your app. See > >> > >> http://logback.qos.ch/manual/configuration.html#stopContext > >> > >> Let us know if this helps, > >> > >> On 6/13/2013 1:21 PM, Mads Bondo Dydensborg wrote: > >>> Hi all > >>> > >>> I have a feeling that this is a FAQ, but my google-foo failed me. > >>> > >>> We provide an application that uses slf4j. The users configure it, in > >>> logback.xml, to use, among other things, an async appender. > >>> > >>> Tomcat complains about this, when redeploying or shutting down: > >>> > >>> SEVERE: The web application [/openformat] appears to have started a > >>> thread named [AsyncAppender-Worker-Thread-2] but has failed to stop it. > >>> This is very likely to create a memory leak. > >>> > >>> I found this issue/request: > >>> http://bugzilla.slf4j.org/show_bug.cgi?id=201 (Need ability to shutdown > >>> loggers and flush appenders), but it does not seem that this request has > >>> been honored. > >>> > >>> So, what is the recommended way to solve this? We would like to not > >>> hardcode the app to use logback (as it could potentially be used with > >>> log4j), but there seems to be no way to stop an async appender that the > >>> users have configured in? > >>> > >>> Thanks in advance. > >>> > >>> Mads > >>> > >>> -- > >>> > >>> Med venlig hilsen/Regards > >>> > >>> Chefarkitekt/Chief Architect cand.scient.dat, Ph.d., Mads Bondo Dydensborg > >>> > >>> Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 29 84 > >>> 00 42 > >>> > >>> > >>> > >>> _______________________________________________ > >>> Logback-user mailing list > >>> Logback-user(a)qos.ch > >>> http://mailman.qos.ch/mailman/listinfo/logback-user > >>> > >> _______________________________________________ > >> Logback-user mailing list > >> Logback-user(a)qos.ch > >> http://mailman.qos.ch/mailman/listinfo/logback-user > >> > >> > >> > > > -- Med venlig hilsen/Regards Chefarkitekt/Chief Architect cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 29 84 00 42

1 1

Re: [logback-user] Configuring for detailed information on trace level, for entry and exit extensions
by Mads Bondo Dydensborg 14 Jun '13

14 Jun '13

(Moved to list, such that google can pick this up for the benefit of others) Thanks a bunch! I am using (or rather, the people configuring the log is using) AsyncAppender. I had totally missed that you need to set includeCallerData to true, mea culpa. Thanks & Kind regards Mads Torsdag 13 juni 2013 17:59:05 skrev Ceki Gülcü: > > Are the logging evetns sent over the network? Are you using > AsyncAppender? You need to set includeCallerData to true. > > http://logback.qos.ch/manual/appenders.html#asyncIncludeCallerData > > On 6/13/2013 5:29 PM, Mads Bondo Dydensborg wrote: > > Hi Ceki > > > > Thanks! > > > > We are using slf4j - the language is java, configuration through logback.xml and binding using Maven. > > We are using Rhino to run som JavaScript, but the problems are "everywhere", not related to JavaScript. > > > > There are no AOP. > > > > Here is a stacktrace before a log statement (In one of the first constructors. I have no statements where the class, method or line information is shown, so any log statement will do, I reckon.). The stacktrace looks "correct", ie, have methodnames, linenumbers, etc. that makes sense to me ;-) > > > > java.lang.Exception: testing > > at dk.dbc.openformat.EnvironmentFactory.<init>(EnvironmentFactory.java:107) > > at dk.dbc.openformat.OpenFormatServletContextListener.contextInitialized(OpenFormatServletContextListener.java:124) > > at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:579) > > at org.mortbay.jetty.servlet.Context.startContext(Context.java:156) > > at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1215) > > at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:548) > > at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:348) > > at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:107) > > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > > at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:151) > > at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) > > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > > at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:151) > > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > > at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) > > at org.mortbay.jetty.Server.doStart(Server.java:222) > > at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > > at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) > > at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:384) > > at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:320) > > at org.mortbay.jetty.plugin.Jetty6RunWar.execute(Jetty6RunWar.java:67) > > at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) > > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) > > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > > at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > > > > Any help greatly appreciated! > > > > Kind regards > > > > Mads > > > > Torsdag 13 juni 2013 15:23:04 skrev Ceki Gülcü: > >> > >> Hi Mads, > >> > >> The character is output '?' by %class (or %C), %method (or %M), %line > >> (or %L) if caller information could not be computed. Incorrect caller > >> information is usually due to logging via wrappers or interceptors in > >> dynamic languages. In other words, computation of caller information is > >> sensitive to the method invocation stack. > >> > >> Are you using a dynamic language, AOP or a logger wrapper? > >> > >> In any case, an actual stack trace would help understanding the problem. > >> For example, if the following logger call results in incorrect caller info: > >> > >> logger.debug("Hello world"); > >> > >> print a stack trace just before (or after) that logger invocation, e.g. > >> > >> new Exception("testing").printStackTrace(); > >> logger.debug("Hello world"); > >> > >> I'd appreciate if you could post the stack trace here. > >> > >> Best regards, > >> > >> > >> Can you post a stack trace > >> > >> > >> On 6/13/2013 2:43 PM, Mads Bondo Dydensborg wrote: > >>> Hi there. > >>> > >>> Using > >>> <slf4j.version>1.7.5</slf4j.version> > >>> <logback.version>1.0.13</logback.version> > >>> > >>> And, with the following in logback.xml: > >>> > >>>  > >>> <encoder> > >>>  > >>>  > >>> <pattern>%d{ISO8601} [%thread] rid:%X{trackingId} %-5level %class{5}.%M:%L - %msg%n</pattern> > >>> <immediateFlush>true</immediateFlush> > >>> <outputPatternAsHeader>true</outputPatternAsHeader> > >>> </encoder> > >>> > >>> This outputs > >>> #logback.classic pattern: %d{ISO8601} [%thread] rid:%X{trackingId} %-5level %class{5}.%M:%L - %msg%n > >>> 2013-06-13 12:55:49,486 [main] rid: TRACE ?.?:? - entry > >>> > >>> Changing to the first commented pattern, gets me: > >>> > >>> #logback.classic pattern: %d{ISO8601} [%thread] rid:%X{trackingId} %-5level %logger{5} - %msg%n > >>> 2013-06-13 14:35:20,450 [main] rid: TRACE d.d.o.EnvironmentFactory - entry > >>> > >>> Second commented pattern: > >>> #logback.classic pattern: %d{ISO8601} [%thread] rid:%X{trackingId} %-5level %logger{5}.%M:%L - %msg%n > >>> 2013-06-13 14:36:37,689 [main] rid: TRACE d.d.o.EnvironmentFactory.?:? - entry > >>> > >>> Any idea what I am doing wrong here? The point was to get method name and line numbers, as per this: > >>> http://logback.qos.ch/manual/layouts.html#conversionWord > >>> > >>> Any clues? > >>> > >>> Thanks in advance. > >>> > >>> Mads > >>> > >> _______________________________________________ > >> Logback-user mailing list > >> Logback-user(a)qos.ch > >> http://mailman.qos.ch/mailman/listinfo/logback-user > >> > >> > >> > > > -- Med venlig hilsen/Regards Chefarkitekt/Chief Architect cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 29 84 00 42

1 0

Relevent calss in logback for the class org.apache.log4j.helpers.LogLog in log4j
by Govardhana 13 Jun '13

13 Jun '13

Hi, I am updating my project to use logback instead of log4j. In few places "LogLog" class has been used to print the log. Ex: org.apache.log4j.helpers.LogLog.error("Logger failed to log"); Please let me know which class i can you use in logback to get the same result. Thanks in Advance....! Regards, Reddy -- View this message in context: http://logback.10977.n7.nabble.com/Relevent-calss-in-logback-for-the-class-… Sent from the Users mailing list archive at Nabble.com.

2 6

Configuring for detailed information on trace level, for entry and exit extensions
by Mads Bondo Dydensborg 13 Jun '13

13 Jun '13

Hi there. Using <slf4j.version>1.7.5</slf4j.version> <logback.version>1.0.13</logback.version> And, with the following in logback.xml:  <encoder>   <pattern>%d{ISO8601} [%thread] rid:%X{trackingId} %-5level %class{5}.%M:%L - %msg%n</pattern> <immediateFlush>true</immediateFlush> <outputPatternAsHeader>true</outputPatternAsHeader> </encoder> This outputs #logback.classic pattern: %d{ISO8601} [%thread] rid:%X{trackingId} %-5level %class{5}.%M:%L - %msg%n 2013-06-13 12:55:49,486 [main] rid: TRACE ?.?:? - entry Changing to the first commented pattern, gets me: #logback.classic pattern: %d{ISO8601} [%thread] rid:%X{trackingId} %-5level %logger{5} - %msg%n 2013-06-13 14:35:20,450 [main] rid: TRACE d.d.o.EnvironmentFactory - entry Second commented pattern: #logback.classic pattern: %d{ISO8601} [%thread] rid:%X{trackingId} %-5level %logger{5}.%M:%L - %msg%n 2013-06-13 14:36:37,689 [main] rid: TRACE d.d.o.EnvironmentFactory.?:? - entry Any idea what I am doing wrong here? The point was to get method name and line numbers, as per this: http://logback.qos.ch/manual/layouts.html#conversionWord Any clues? Thanks in advance. Mads -- Med venlig hilsen/Regards Chefarkitekt/Chief Architect cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 29 84 00 42

2 2

Shutting down async appenders, when using logback through slf4j
by Mads Bondo Dydensborg 13 Jun '13

13 Jun '13

Hi all I have a feeling that this is a FAQ, but my google-foo failed me. We provide an application that uses slf4j. The users configure it, in logback.xml, to use, among other things, an async appender. Tomcat complains about this, when redeploying or shutting down: SEVERE: The web application [/openformat] appears to have started a thread named [AsyncAppender-Worker-Thread-2] but has failed to stop it. This is very likely to create a memory leak. I found this issue/request: http://bugzilla.slf4j.org/show_bug.cgi?id=201 (Need ability to shutdown loggers and flush appenders), but it does not seem that this request has been honored. So, what is the recommended way to solve this? We would like to not hardcode the app to use logback (as it could potentially be used with log4j), but there seems to be no way to stop an async appender that the users have configured in? Thanks in advance. Mads -- Med venlig hilsen/Regards Chefarkitekt/Chief Architect cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 29 84 00 42

2 2

Localtime(from server) to be printed instead of GMT
by Kriti Wadhwa 13 Jun '13

13 Jun '13

Hello, As per my understanding currently using following pattern: <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %class{0} %msg%n</pattern> </encoder> Time stamp printed in log files display time in GMT format by default. Using %date{HH:mm:ss.SSS,Australia/Perth} we can set the timezone to a particular value (In this case Australia/Perth). In my application I need: Time zone to be picked up from local server (/etc/localtime) where the application is running instead of setting it to a specific value in xml as shown above. How can I do this using logback.xml ? Please suggest. Thanks, Kriti =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

4 5