November 2010 - logback-user

Can the SiftingAppender discard 'unknown' log events?
by Colm.McDonnell＠rbs.com 24 Nov '10

24 Nov '10

I am using the SiftingAppender to isolate log events with a specific MDC key. This works really well, giving me high signal:noise ratio log files for specific invocations on particular process etc etc. However the SiftingAppender (or rather the MDCBasedDiscriminator) insists on the provision of a 'default value'. If I supply this default value (e.g. "unknown") then all unmatched events will be directed to unknown.log. But the 'other' log events are already logged separately so the entries in 'unknown.log' are unwanted duplicates (for me). Ideally I would use the sifting appender for a particular use case and let everything else be logged the way it is currently logged i.e. I would lke to provide no default value and have the appender understand this to mean 'ignore any events which do not match the given key' but that seems not to be supported so I'm trying to figure out how to either discard the unwanted events or to incorporate my existing logging into the sifting appender. I'd be grateful if someone could suggest how I might do either of the following: * somehow discard the 'unknown' events discriminated by the SiftingAppender i.e. to ignore them completely as they are already logged elsewhere or * figure out how to control the 'unknown' log events so that Ii can direct them to an 'everything else' appender which is distinct from the 'isolated events' appender I've included an example of the config below. The STDOUT appender is the main appender, there's a wrapper process running the java app and this wrapper process redirects STDOUT to its own log file (with its own rolling rules etc) therefore the 'everything else' events are all logged to STDOUT. I'd like the SIFTER to only log events for which it gets a match otherwise we end up with the same events in STDOUT and in "unknown.log". Alternatively, if there is a way to configure SIFTER such that it wraps the STDOUT appender and the unmatched events are only directed to that appender then that would work too. I have tried several configurations but I cannot associate the unmatched events with a specific appender. <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>[%-5p] [%t] %logger{5}: %m%n</pattern> </encoder> </appender> <appender name="SIFTER" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <Key>isolatedLogName</Key> <defaultValue>unknown</defaultValue> </discriminator> <sift> <appender name="${isolatedLogName}" class="ch.qos.logback.core.FileAppender"> <File>${log.path:-target/log}/${isolatedLogName}.log</File> <encoder> <Pattern>%d | %-5p | %logger{5} | %m%n</Pattern> </encoder> </appender> </sift> </appender>  <root level="INFO"> <appender-ref ref="STDOUT" /> <appender-ref ref="SIFTER"/> </root> </configuration> For example: I tried this: <appender name="SIFTER" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <Key>isolatedLogName</Key> <defaultValue>everythingElse</defaultValue> </discriminator> <sift> <appender name="isolatedLogName" class="ch.qos.logback.core.FileAppender"> <File>${log.path:-target/log}/${isolatedLogName}.log</File> <encoder> <Pattern>%d | %-5p | %logger{5} | %m%n</Pattern> </encoder> </appender> <appender name="everythingElse" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>[%-5p] [%t] %logger{5}: %m%n</pattern> </encoder> </appender> </sift> </appender> And logback created two files - everythingElse.log and <the real value associated with the isolatedLogName key>.log - then wrote all output to the "everythingElse" appender. I was trying to tell it to do this: "if the key's value is the default value then ignore it or if that is not possible then direct the output to the appender named after that value otherwise direct to the other appender". Any help appreciated, thanks. *********************************************************************************** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 10, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions. This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland N.V. including its affiliates ("RBS group") does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the RBS group in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our website at www.rbs.com ***********************************************************************************

3 4

Use web application name in logback configuration
by Pradnya Gawade 23 Nov '10

23 Nov '10

Hi, Can I use my Spring web application name in the logback configuration dynamically? I know logback can read from properties file specified under <property> or it can read from the system variables but is it possible to use some dynamic data like web application name in the configuration? Thanks, Pradnya

2 3

Delete log file
by pwillems66＠zonnet.nl 19 Nov '10

19 Nov '10

> It is not clear to me what you mean by "test". Is a test the class > containing the various test methods or does "test" refer to each test > method? For example, Given the MyTest class mention in my previous > post, is MyTest the "test" or are the methods a() and b() "tests"? > If the latter, you could try, > public class MyTest { > Logger logger = LoggerFactory.getLogger(MyTest.class); > > @Test a() { > MDC.put("testname", "myTest_a"); > logger.info("a says hello"); > ... > } > > @Test b() { > MDC.put("testname", "myTest_b"); > logger.info("b says hello"); > ... > } > } Let me try to explain what I am after: First: For me a "test" is a process. Executing 1,2,3,n-1,n method which could log information. But to keep it simple, executing method a() in class MyTest is a test (Create/append/truncate file myTest_a.log) An other test, executing method b() in class MyTest is a test (Create/append/truncate file myTest_b.log) Second: Lets use your class and methods for a simple application: Public Class MyApp { public static void main(String args[]) { MyTest myTest = new MyTest(); myTest.a(); myTest.b(); if (errors in method a) { delete file (myTest_a.log) myTest.a(); } } } If you run the code in file myTest_a.log there are 2 lines mentioned: a says hello a says hello because the file is in use. In case there are errors the (call myTest.a() again) the file myTest_a.log must be deleted and the next call must recreate the file. -Patrick

1 0

Problem with Syslog appender
by Pradnya Gawade 18 Nov '10

18 Nov '10

Hi, I have following requirements when sending the log from a java web application to syslog server: 1. When logging the stack trace in case of exceptions, all the stack strace should be seen as a single message. 2. Need to send either or all of the following information in logs- name of the web application, URL, version of the application. As per my knowledge, Syslog appender of Logback doesnot fit to above requirements. I am also looking for any other logging APIs which can satisfy these requirements. Any ideas? Thanks in advance. - Pradnya

3 7

Re: [logback-user] Delete log file
by pwillems66＠zonnet.nl 18 Nov '10

18 Nov '10

> Hi Patrick, > Sifting appender could probably help. Here is a sample config file: public class MyTest { Logger logger = LoggerFactory.getLogger(Foo.class); @Before public void setUp() { MDC.put("testname", "myTest"); } @Test a() { logger.info("a says hello"); ... } @Test b() { logger.info("b says hello"); ... } } public class MyOtherTest { Logger logger = LoggerFactory.getLogger(Foo.class); @Before public void setUp() { MDC.put("testname", "MyOtherTest"); } @Test x() { logger.info("a says hello"); ... } } >> Let us know if it works... >> -- Ceki Hi Ceki, It works except for the delete. When I call the test (class) MyTest (multiple times) logback don't delete the log file but append it. The first time when the Logger initialize the file is truncated but not for the second and more times until the Logger must initialize again. -Patrick

2 1

Re: [logback-user] Delete log file
by pwillems66＠zonnet.nl 18 Nov '10

18 Nov '10

Hi, The prudent propertie doesn't work. Any other idea? It looks like the log file is in use. Is their a way to 'unlock' that use by code? This is what I must realize: For every test I need to create a log file. When the same test start again the previous file must be deleted (or renamed and delete thereafter) and a new one created. Also (test is not running) it must be possible to delete the log file. -Patrick pwillems66 at zonnet.nl wrote: > Maybe someone else have a (different) solution? FileAppender.setPrudent() looks promising for this purpose. However, using the example from PrudentTimeBasedRolling.xml, when I rm the file it is not recreated on the next log statement. Also, if it did work, it doesn't support your file appender, but maybe it is ok to change that. http://logback.qos.ch/codes.html#tbr_fnp_prudent_unsupported says, > prudent mode is not allowed in conjuction with a FixedWindowRollingPolicy. -Gordon

2 1

Delete log file
by pwillems66＠zonnet.nl 17 Nov '10

17 Nov '10

We think about it but I doubt it. Maybe someone else have a (different) solution? > With append=false, log a start message (e.g. "Starting"), which >will > then overwrite the file. Is that good enough for the needs? > On Tue, Nov 16, 2010 at 10:47 AM, <pwillems66 at zonnet.nl> >wrote: >> Hi, >> >> For every test we do, we need a log file. >> If the test fails, the log file can be viewed and the errors can be fixed. >> If the errors are fixed and the test runs again and there are no errors, I >> want to delete this log file. >> Is it possible to delete a log file? (While file is is use by logback!) >> If yes, how? >> >> My configuration is: >> <?xml version="1.0" encoding="UTF-8" ?> >> <configuration> >> >> <appender name="RootSiftAppender" >> class="ch.qos.logback.classic.sift.SiftingAppender"> >> <append>false</append> <discriminator> >> <Key>testname</Key> >> <DefaultValue>testrun</DefaultValue> >> </discriminator> >> <sift> >> <appender name="FILE-${testname}" >> class="ch.qos.logback.core.rolling.RollingFileAppender"> >> <File>${testname}.log</File> >> <rollingPolicy >> class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> >> <FileNamePattern>${testname}.%i.log</FileNamePattern> >> <MinIndex>1</MinIndex> >> <MaxIndex>1</MaxIndex> >> </rollingPolicy> >> <triggeringPolicy >> class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> >> <MaxFileSize>5MB</MaxFileSize> >> </triggeringPolicy> >> <layout class="ch.qos.logback.classic.PatternLayout"> >> <Pattern>%d{ISO8601} - %msg%n</Pattern> >> </layout> >> </appender> >> </sift> >> </appender> >> <root level="error"> >> <appender-ref ref="RootSiftAppender" /> >> </root> >> </configuration> >> >> _______________________________________________ >> Logback-user mailing list >> Logback-user at qos.ch >> http://qos.ch/mailman/listinfo/logback-user >> >>

2 1

Delete log file
by pwillems66＠zonnet.nl 17 Nov '10

17 Nov '10

Hi, For every test we do, we need a log file. If the test fails, the log file can be viewed and the errors can be fixed. If the errors are fixed and the test runs again and there are no errors, I want to delete this log file. Is it possible to delete a log file? (While file is is use by logback!) If yes, how? My configuration is: <?xml version="1.0" encoding="UTF-8" ?> <configuration> <appender name="RootSiftAppender" class="ch.qos.logback.classic.sift.SiftingAppender"> <append>false</append> <discriminator> <Key>testname</Key> <DefaultValue>testrun</DefaultValue> </discriminator> <sift> <appender name="FILE-${testname}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${testname}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <FileNamePattern>${testname}.%i.log</FileNamePattern> <MinIndex>1</MinIndex> <MaxIndex>1</MaxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>5MB</MaxFileSize> </triggeringPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{ISO8601} - %msg%n</Pattern> </layout> </appender> </sift> </appender> <root level="error"> <appender-ref ref="RootSiftAppender" /> </root> </configuration>

2 1

Unable to see ch.qos.logback.classic.jmx.Configurator folder within JConsole?
by Joshua White 15 Nov '10

15 Nov '10

Hello, I am attempting to configure logback to use JMX. I have used the "<jmxConfigurator />" within my xml file and I see the following in the log: 09:02:16,991 |-INFO in ch.qos.logback.classic.LoggerContext[mycompany-portal] - Could NOT find resource [logback-test.xml] 09:02:17,022 |-INFO in ch.qos.logback.classic.LoggerContext[mycompany-portal] - Found resource [logback.xml] at [file:/C:/source/mycompany/mycompany-core-jar/bin/logback.xml] 09:02:17,179 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeFilter scanning period to 15 minutes 09:02:17,179 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@18661866 - Will scan for changes in file [C:\source\mycompany\mycompany-core-jar\bin\logback.xml] every 900 seconds. 09:02:17,179 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 09:02:17,179 |-INFO in ch.qos.logback.classic.joran.action.ContextNameAction - Setting logger context name as [mycompany-portal] *09:02:17,179 |-INFO in ch.qos.logback.classic.joran.action.JMXConfiguratorAction - begin* 09:02:17,647 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.FileAppender] 09:02:17,647 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE] 09:02:17,679 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 09:02:17,679 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [encoder] on top of the object stack. 09:02:17,757 |-INFO in ch.qos.logback.core.FileAppender[FILE] - File property is set to [c:/temp/oep/mycompany-portal.log] 09:02:17,757 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [com.mycompany] to DEBUG 09:02:17,757 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [com.mycompany] to true 09:02:17,757 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.springframework] to INFO 09:02:17,757 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.springframework] to true 09:02:17,757 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO 09:02:17,757 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to Logger[ROOT] 09:02:17,757 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration. When I start JConsole (IBM's version...) I only see two folders. I would expect to see a folder for "ch.qos.logback.classic.jmx.Configurator". Here is what I see: Shouldn't the logback folder be in root with these two folders? JMImplementation WebSphere Here is what I am using: Logback 0.9.24 Websphere 6.1 Any thoughts or recommendations?

2 2

Lilith 0.9.40 has been released! (supporting log4j & jul, too!)
by Joern Huxhorn 11 Nov '10

11 Nov '10

http://lilith.huxhorn.de Release Notes - Color-Schemes (as used by saved conditions, for example) can now be defined partially, i.e. one condition can set a border while the text-color might be defined by a different condition. - Maps, e.g. MDC, are now sorted by key-value in the details view. This was suggested by Joe. - Added preferences to check for pre-release versions in addition to release versions. Off by default. - Added -T/--print-timestamp command line argument that prints the timestamp and date of build. - If the used version is a SNAPSHOT, Lilith will always check for a new SNAPSHOT pre-release regardless of the "Check for updates on startup." settings. - Enhanced "Check for update" functionality. No more false update warnings in case of SNAPSHOT pre-releases. A new release takes precedence over a new pre-release. - SNAPSHOT pre-releases will now contain the date and time of the build in the window title. - Added support for java.util.logging SocketHandler. Lilith is listening on port 11020 for incoming connections. I'd still recommend to switch to SLF4J/Logback, though! (Ticket 35) - Added JSON-Appenders and JSON-Receivers. Lilith is listening for message-based JSON-Events on port 10030 (uncompressed) and 10031 (compressed). Zero-delimited JSON-Events are consumed on port 11010. Check out the expected JSON data at http://sourceforge.net/apps/trac/lilith/wiki/LilithJsonFormat - Replaced Commons-CLI with JCommander. Very nice replacement. I'd like to take this opportunity to thank Cedric Beust for his great (and fast!) support! You should seriously check JCommander out if your application is handling command line arguments at all. - Added support for Log4j SocketAppender. Lilith is listening on port 4445 for incoming connections. I'd still recommend to switch to SLF4J/Logback, though! (Ticket 32) - Fixed glitch in case of "Find next"/"Find prev" while search is already running. Additional searches are now ignored. - Added "Find previous active" (*command* T) and "Find next active" (*command* shift T) functionality to quickly jump to events that match any active condition. (Ticket 93) - Added "Export" functionality which exports the currently selected view into a Lilith file. (Ticket 92) - Added default condition name to preferences. It's preselected for every new view. This was suggested by Lothar Cezanne. - Polling events every 100ms instead of every 2s. This results in less congestion and a much snappier feeling. - Added --export-preferences <file> and --import-preferences <file> commandline options to be able to export and import all preferences. This was requested by Gareth Doutch (gdoutch). (Ticket 81) - Added an additional executable lilith-all.jar containing all dependencies as another download option. This was requested by Adrien Sales. - Added ability to define a sound for WARN-level events, but without any assigned default sound. This was requested by Adrien Sales. - Added F1 as shortcut for Help. This was requested by Adrien Sales. - Fixed several issues in case of log files that are recreated by <append>false<append> in FileAppender. Those were all raised by Jeff Jensen (jeffjensen). Thank you very much! (Ticket 84, 88, 90) - Fixed the regression that the internal Lilith log wouldn't show up in the menu anymore. (Ticket #85) - Changed update interval of opened files from 5 seconds to 1 second. - Spring 3.0.5.RELEASE - Groovy 1.7.5 - SLF4J 1.6.1 - Logback 0.9.26 Known Issues - Selection in the HTML view is currently somewhat buggy, especially in case of scaled view. This is a limitation of Flying Saucer that's used as the XHTML renderer. - cat and tail are currently still experimental features. AccessEvent isn't (and can't be) supported yet. LoggingEvent isn't fully supported, either. And finally: Sulky and Lilith builds have been switched from Maven to Gradle. pom files are still maintained but mainly because of Sonar. I'd like to take this opportunity and thank the great Gradle community from the #gradle channel on irc.codehaus.org, especially - but not exclusively! - adam (Adam Murdoch), xlson (Leonard Axelsson) and sebersole (Steve Ebersole). Thank you very much! If you haven't taken a look at Gradle yet you should definitely do so now or in the near future... Cheers, Joern.

1 0