- logback-user - mailman3.qos.ch

AUTO: Manfred Kuhlmann is out of office. (Rückkehr am 12.02.2013)
by manfred.kuhlmann＠steria-mummert.de 08 Feb '13

08 Feb '13

Ich werde ab dem 08.02.2013 nicht im Büro sein. Ich kehre zurück am 12.02.2013. I will be out of the office starting 08.02.2013. I will be back on 12.02.2013. Ihre Nachricht werde ich nach meiner Rückkehr beantworten. Mit freundlichen Grüßen Manfred Kuhlmann Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "Re: [logback-user] commons-logging -> sl4j -> logback" gesendet am 08.02.2013 09:24:27. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. Steria Mummert Consulting AG Vorsitzender des Aufsichtsrates: Jürgen Sponnagel - Vorstand: Dr. Fritz Moser (Vors.), Dr. Reinhard Liedl Gesellschaftssitz: Hamburg - HR B 61 116 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351 Bitte denken Sie an Ihre Verantwortung gegenüber der Umwelt: Jede ausgedruckte E-Mail verursacht ca. 0,3 Gramm CO2 pro Seite. Diese Nachricht kann vertrauliche Informationen enthalten und ist allein für den Adressaten bestimmt. Wenn Sie nicht der rechtmäßige Empfänger sind, sind der Zugriff, die Weiterleitung, das Kopieren, die Veröffentlichung oder anderweitige Verwendung des Inhalts untersagt. In diesem Fall bitten wir Sie, den Absender unverzüglich zu informieren und diese E-Mail sowie sämtliche Kopien dieser E-Mail zu löschen. Der Inhalt von E-Mails innerhalb des Netzwerks kann überprüft werden, um die Übereinstimmung mit den geltenden Firmenrichtlinien und Vorgehensweisen zu gewährleisten. E-Mails können auf dem Transportweg von Dritten verändert werden, so dass deren Vollständigkeit und Echtheit nicht garantiert werden können. This e-mail communication may contain confidential information and is intended only for the recipient. If you are not the intended recipient you are not allowed to read, copy, distribute, publicize or use the content of this e-mail in any way. Please notify the sender and delete the e-mail and any copies of it. The content of e-mails within our network may be monitored to ensure compliance with company policies and procedures. E-mails can be alterated by third parties in transit. Therefore any e-mail is susceptible to alteration and its integrity cannot be assured.

1 0

programmatic configuration to log to file
by Steve Prior 07 Feb '13

07 Feb '13

Based on some examples I cobbled together the following code to programmatically configure logback to write its output to a file (I don't like having config files around), but the output still goes to stdout in addition to the file. Can anyone give me a clue how I can only have the output go to the specific file and not stdout? Thanks Steve LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory(); FileAppender<ILoggingEvent> fileAppender = new FileAppender<ILoggingEvent>(); fileAppender.setContext(loggerContext); fileAppender.setFile(ConcurrencyExample.class.getSimpleName() + ".log"); PatternLayout pl = new PatternLayout(); pl.setPattern("%d %5p %t [%c:%L] %m%n)"); pl.setContext(loggerContext); pl.start(); fileAppender.setLayout(pl); fileAppender.start(); // attach the rolling file appender to the logger of your choice Logger logbackLogger = loggerContext.getLogger(ConcurrencyExample.class); logbackLogger.addAppender(fileAppender); // OPTIONAL: print logback internal status messages StatusPrinter.print(loggerContext); // log something logbackLogger.info("hello");

4 6

how configure OSGi-over-slf4j ?
by Cristiano Gavião 07 Feb '13

07 Feb '13

Hi, I would like to try OSGi-over-slf4j. I have installed it into an equinox product, set a low start level to it. but couldn't see any result. could someone point me to any example of its use? thanks Cristiano

2 1

TimeBasedRollingPolicy failed to rollover logfiles yesterday, but I see no RolloverFailure?
by Robert Kuhar 06 Feb '13

06 Feb '13

I have an appender configured like... <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>%m%n</pattern> </encoder> </appender> ... <root level="info"> <appender-ref ref="DAILY_ROLLING" /> <appender-ref ref="SYSLOG" /> </root> ...which typically has the effect of logging current data to the dm.log file and everyday at midnight rolling over the dm.log into a file named for the date, dm.20130205.log. Yesterday, however, for the first time ever, this rollover did not occur on any of my production servers. My dm.log file now has 2 days worth of data and I am wondering what went wrong? I expected to find a RolloverFailure or some indication of what went wrong to be laying in the dm.log file but there is nothing there. I have never seen this mechanism fail in either logback or log4j and am at a loss as to where to start troubleshooting. Where do I look to figure out what went wrong in logback? Am I correct in expecting some ch.qos.logback.core.rolling.RolloverFailure stacktrace to be appearing in my dm.log file or does it only go there if my app is correctly catching and logging all throwables?

1 0

Externalized Logback configuration for web applications
by Perryn Fowler 01 Feb '13

01 Feb '13

Hello, I have a logging use case that I would think was relatively common, but that does not seem to be supported particularly well by logback. I wanted to see what the logback community thinks/advises. The details of the use case - I am writing java web apps to be deployed to JEE web containers. - I want the logging config to be external to the wars, so that I can use the same wars in different environments, but configure logging differently. - I want to be able to deploy several different wars to the same web container and have them use different logging configurations. The logback documentation seems to push towards either packaging the logback config in the wars, or sharing an external logging config between them. (Whereas I want separate external logging configuration for each war) I hope that makes sense. The JNDI support described here: http://logback.qos.ch/manual/loggingSeparation.html looks like it might be of use, but it does seem to require that the config files are placed in WEB-INF/classes and I would prefer they are completely external to the war. I have found a number of people who have coded up their own solutions, notably: http://blog.iprofs.nl/tag/logback/ and https://bowerstudios.com/node/896 That doesn't look too bad, but wondering what the community thinks of these approaches -- ----------------------- Perryn Fowler

6 10

AsyncAppender configuration on groovy
by David Antonio Jiménez Xolalpa 01 Feb '13

01 Feb '13

For the AsyncAppender, the xml configuration uses the tag "appender-ref". How can a reference to another appender be set on groovy? I tried the xml-to-groovy tool with no success.

1 0

turn off stack traces in one appender, leave them on in another
by Steve Cohen 30 Jan '13

30 Jan '13

Given a configuration with two appenders, one file based and the other network-based, I would like to be able to code log statements with a throwable parameter in which the file-based one would append the stack-trace information contained in the throwable, but the network-based appender would not. The network-based appender is home-brewed, descending from JMSAppenderBase. Is there a hook in the appender hierarchy that would allow it to turn off appending of the stack trace for that appender while letting other appenders print the stack trace? Thanks.

1 1

How to determine if the Logback Framemwork is properly configured?
by Brett Walker 12 Jan '13

12 Jan '13

Hi, I have a need to determine programmatically if the Logback Framework if properly configured. I'm aware that if Logback encounters an error during configuration that it prints status messages to the console. I'm writing a standalone GUI application that won't have a console. Also the targeted audience will not be familiar with logs Before the application can proceed past initialization; I need to be assured, programmatically, that the logging framework is properly configured; i.e. that log messages are being written to the log file and no other errors have been occurred. Do I have to scan the status messages for message of WARN and ERROR level or is there some simpler means of determining the configuration status of the Logback framework. Brett

1 0

Access Properties Defined in Logback programmatically
by Charlie Hubbard 11 Jan '13

11 Jan '13

I have an administration console I'm building, and I want to display the logs created in Logback for my application. However, where those logs are stored is different per environment. I have several property files that define where the logs are stored: <configuration> <property resource='log.properties'/> <property resource='log.${ENV:-prod}.properties'/> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${log.dir}/sync.log</file> ...</configuration> I'd like to find the value of ${log.dir} from Logback's Java API. I'd tried the following, but it doesn't have any of the properties defined in the resources. For example: LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory(); String logDir = loggerContext.getProperty("log.dir"); // this always returns null So my question is what API calls should I be using? Thanks Charlie If you'd rather have the stackoverflow karma I originally posted this there: http://stackoverflow.com/questions/14271253/access-properties-defined-in-lo…

2 1

issue with RollingFileAppender when File matches FileNamePattern
by Karl Pietrzak 09 Jan '13

09 Jan '13

Hello everyone! I've come across an issue with RollingFileAppender, but I'm not sure if it's us or logback. <configuration> <timestamp key="currentDate" datePattern="yyyy_MM_dd" /> <appender name="dataServiceRequestLog" class="ch.qos.logback.core.rolling.RollingFileAppender"> <param name="File" value="${the.log.dir}/${currentDate}.WebService.log"/> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${the.log.dir}/%d{yyyy_MM_dd}.WebService.log</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level - %msg%n</pattern> </encoder> </appender> The curious part is that File matches the FileNamePattern for the rolling policy ("${the.log.dir}/${currentDate}.WebService.log" and "${the.log.dir}/%d{yyyy_MM_dd}.WebService.log"). Do you guys think that's OK? The intention is that there's a separate file for every day: - 2013_01_03.WebService.log - 2013_01_04.WebService.log - 2013_01_05.WebService.log - 2013_01_06.WebService.log The issue we're experiencing is seemingly random writes to old log files (e.g., today we saw writes to 2013_01_04.WebService.log). Could this be the rename problem? Perhaps there's a better way to achieve the desired functionality. Is this worth writing a unit test for in RollingFileAppenderTest.java? Any tips are greatly appreciated, thanks!

2 6