- logback-dev - mailman3.qos.ch

BurstFilter code contribution
by Chad LaVigne 25 Mar '09

25 Mar '09

All, Ceki recently sent me a message requesting a Logback port of a filter I contributed to the Log4J project. It's a filter to regulate log message bursts, useful for things like throttling the number of logs sent to an e-mail appender when the database is unavailable. Attached is the port with a simple unit test. If you have any comments or suggestions for improvement just let me know. Cheers, Chad http://simplemindedsoftware.blogspot.com/

1 0

[JIRA] Commented: (LBCORE-41) FixedWindowRollingPolicy MAX_WINDOW_SIZE too small?
by David Vallner (JIRA) 25 Mar '09

25 Mar '09

[ http://jira.qos.ch/browse/LBCORE-41?page=com.atlassian.jira.plugin.system.i… ] David Vallner commented on LBCORE-41: ------------------------------------- I think the hard limit on window size should be removed altogether or replaced with a warning instead of the library just doing something else than I tell it to. Libraries shouldn't establish policy, that's up to my customer's requirements, if their choice ends up lagging them to all hell, so be it. Alternately, it should be made possible to use size triggering with time rolling, so I can have my 100 log files of 5 MB if I want to. > FixedWindowRollingPolicy MAX_WINDOW_SIZE too small? > --------------------------------------------------- > > Key: LBCORE-41 > URL: http://jira.qos.ch/browse/LBCORE-41 > Project: logback-core > Issue Type: Improvement > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: All > Reporter: Mike Mansell > Assignee: Logback dev list > Priority: Minor > > I know it's not a blog but let me first say I've switched from log time use of JCL / log4j and think SLF4J / Logback is awesome so kudos to you guys for getting this out here... simple and powerful.. not much to not like ;-) > I'm curious as to why a window size as small as 12 was chosen here. I realize the renaming of all files within the window gets more expensive as the window increases but it seems prohibitive for people with larger logging requirements. Moreover, the fact that it is final means I can't override this either although I realize it is rather trivial to build my own implementation. > I have a project that generates a tremendous amount of logging currently (about 100MB every 6 minutes) and in my current setup have issues with files over 2GB. With the current MAX_WINDOW_SIZE I can only keep a days worth of logs! > If the rename is a big deal a rolling policy that just uses the index as a cyclic sequence should work fine or are there other reasons to cap this at something so low? > I could submit an implementation back if you like but just curious to get your feedback and any reasoning I might be missing on keeping the window size so low. > Thanks again for a great product! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBCLASSIC-118) Provide means to redirect Outputstream to Logger
by Papick G. Taboada (JIRA) 24 Mar '09

24 Mar '09

Provide means to redirect Outputstream to Logger ------------------------------------------------ Key: LBCLASSIC-118 URL: http://jira.qos.ch/browse/LBCLASSIC-118 Project: logback-classic Issue Type: New Feature Reporter: Papick G. Taboada Assignee: Logback dev list It would be nice to have some util class / convinience method to send the content of an outputstream to an logger. Somehow it should be possible - to keep the outputstream "in a whole" - to define the loglevel Something like LOG.info("Some title information", refToTheOutputStream); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBCLASSIC-117) Log context based log splitting in SocketServer
by Rick Janda (JIRA) 24 Mar '09

24 Mar '09

Log context based log splitting in SocketServer ----------------------------------------------- Key: LBCLASSIC-117 URL: http://jira.qos.ch/browse/LBCLASSIC-117 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: unspecified Reporter: Rick Janda Assignee: Logback dev list Hello logback team, I have the following setup: I have several web applications running in the same Tomcat instance. The JNDIContextSelector is used to give every deployed webapp its own logging context. The logging events are transmitted to a SocketServer. On the side of the SocketServer I want to split the logging events based on their log context to different files. My idea was to use filters, that filter according the logging context name. But this context name seems to be not reachable from within a filter. Would it be possible to add the logging context name as property to the LoggingEvent class that the name is available on the socket server side? Or add another means to accomplish the logging event splitting on the SocketServer side? This would really simplify our setup as of we would only need one SocketServer for all the Webapps. Thanks in advance for your help. Kind regards, Rick -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

svn commit: r2260 - logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift
by noreply.ceki＠qos.ch 23 Mar '09

23 Mar '09

Author: ceki Date: Mon Mar 23 17:19:38 2009 New Revision: 2260 Added: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/ContextBasedDiscriminator.java Log: ContextBasedDiscriminator allows SiftingAppender to separate logging based on the context name. This fits nicely the requirements expressed in LBCLASSIC-117 Added: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/ContextBasedDiscriminator.java ============================================================================== --- (empty file) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/ContextBasedDiscriminator.java Mon Mar 23 17:19:38 2009 @@ -0,0 +1,85 @@ +/** + * Logback: the generic, reliable, fast and flexible logging framework. + * + * Copyright (C) 2000-2008, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ +package ch.qos.logback.classic.sift; + +import ch.qos.logback.classic.spi.ILoggingEvent; +import ch.qos.logback.core.sift.Discriminator; +import ch.qos.logback.core.spi.ContextAwareBase; + +/** + * This discriminator essentially returns the value mapped to an MDC key. If the + * said value is null, then a default value is returned. + * + * <p>Both Key and the DefaultValue are user specified properties. + * + * @author Ceki Gülcü + * + */ +public class ContextBasedDiscriminator extends ContextAwareBase implements + Discriminator<ILoggingEvent> { + + private static final String KEY = "contextName"; + private String defaultValue; + private boolean started = false; + + public ContextBasedDiscriminator() { + } + + /** + * Return the name of the current context name as found in the logging event. + */ + public String getDiscriminatingValue(ILoggingEvent event) { + String contextName = event.getLoggerContextVO().getName(); + + if (contextName == null) { + return defaultValue; + } else { + return contextName; + } + } + + public boolean isStarted() { + return started; + } + + public void start() { + started = true; + } + + public void stop() { + started = false; + } + + public String getKey() { + return KEY; + } + + public void setKey(String key) { + throw new UnsupportedOperationException("Key cannot be set. Using fixed key "+KEY); + } + + /** + * @see #setDefaultValue(String) + * @return + */ + public String getDefaultValue() { + return defaultValue; + } + + /** + * The default context name in case the context name is not set for the + * current logging event. + * + * @param defaultValue + */ + public void setDefaultValue(String defaultValue) { + this.defaultValue = defaultValue; + } +}

1 0

[JIRA] Commented: (LBCORE-63) Deadlock when running on multiple core processors
by Ceki Gulcu (JIRA) 23 Mar '09

23 Mar '09

[ http://jira.qos.ch/browse/LBCORE-63?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-63: ---------------------------------- In that case, please open a new jira issue. It would also be very helpful if you could provide the full thread dump. Please do not continue to comment on the present issue. (I intend to mark it as closed.) > Deadlock when running on multiple core processors > ------------------------------------------------- > > Key: LBCORE-63 > URL: http://jira.qos.ch/browse/LBCORE-63 > Project: logback-core > Issue Type: Sub-task > Affects Versions: 0.9.9 > Environment: Operating System: Windows > Platform: PC > Reporter: Toni Heimala > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: patch.txt, patch2.txt, patch3.txt > > > When you run logging into same file from many threads on a system that has more than one physical processor (Dual Core for example), a deadlock will occur after a while. This can not be reproduced on HyperThreading processors. Here's an example program that will demonstrate the behavior: > ----------------------------- > Main.java > ----------------------------- > import java.util.Date; > import java.util.concurrent.ScheduledThreadPoolExecutor; > import java.util.concurrent.TimeUnit; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > import ch.qos.logback.classic.LoggerContext; > import ch.qos.logback.classic.joran.JoranConfigurator; > import ch.qos.logback.core.joran.spi.JoranException; > public class Main extends Thread > { > private final static String LOGGER_CONFIGURATION_FILE = "logger.xml"; > private final Logger logger = LoggerFactory.getLogger(Main.class); > > private final long start; > > public Main() > throws JoranException > { > start = new Date().getTime(); > LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); > JoranConfigurator configurator = new JoranConfigurator(); > lc.shutdownAndReset(); > configurator.setContext(lc); > configurator.doConfigure(LOGGER_CONFIGURATION_FILE); > } > > public void start() > { > ScheduledThreadPoolExecutor ex1 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex2 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex3 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex4 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex5 = new ScheduledThreadPoolExecutor(1); > ex1.scheduleAtFixedRate(new Task("EX1"), 10, 10, TimeUnit.MICROSECONDS); > ex2.scheduleAtFixedRate(new Task("EX2"), 10, 10, TimeUnit.MICROSECONDS); > ex3.scheduleAtFixedRate(new Task("EX3"), 10, 10, TimeUnit.MICROSECONDS); > ex4.scheduleAtFixedRate(new Task("EX4"), 10, 10, TimeUnit.MICROSECONDS); > ex5.scheduleAtFixedRate(new Task("EX5"), 10, 10, TimeUnit.MICROSECONDS); > > super.start(); > } > > public void run() > { > try > { > while(true) > { > logger.debug("[MAIN] {}", new Date().getTime() - start); > Thread.sleep(10); > } > } > catch (InterruptedException e) > { > logger.info("[MAIN]: Interrupted: {}", e.getMessage()); > } > } > > public static void main(String[] args) > { > try > { > Main main = new Main(); > main.start(); > } > catch (JoranException e) > { > System.out.println("Failed to load application: " + e.getMessage()); > } > } > } > ------------------------------- > Task.java > ------------------------------- > import java.util.Date; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > public class Task implements Runnable > { > private final Logger logger = LoggerFactory.getLogger(Task.class); > private final Logger logger_main = LoggerFactory.getLogger(Main.class); > private final String name; > private final long start; > > public Task(final String name) > { > this.name = name; > start = new Date().getTime(); > } > public void run() > { > logger.debug("[{}] {}", name, new Date().getTime() - start); > logger_main.debug("[MAIN] - [{}] {}", name, new Date().getTime() - start); > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCORE-63) Deadlock when running on multiple core processors
by Robert Dale (JIRA) 23 Mar '09

23 Mar '09

[ http://jira.qos.ch/browse/LBCORE-63?page=com.atlassian.jira.plugin.system.i… ] Robert Dale commented on LBCORE-63: ----------------------------------- I'm getting that deadlock in logback core (0.9.14 and 0.9.15). No console plugin or socket appenders, just plain RollingFileAppender. > Deadlock when running on multiple core processors > ------------------------------------------------- > > Key: LBCORE-63 > URL: http://jira.qos.ch/browse/LBCORE-63 > Project: logback-core > Issue Type: Sub-task > Affects Versions: 0.9.9 > Environment: Operating System: Windows > Platform: PC > Reporter: Toni Heimala > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: patch.txt, patch2.txt, patch3.txt > > > When you run logging into same file from many threads on a system that has more than one physical processor (Dual Core for example), a deadlock will occur after a while. This can not be reproduced on HyperThreading processors. Here's an example program that will demonstrate the behavior: > ----------------------------- > Main.java > ----------------------------- > import java.util.Date; > import java.util.concurrent.ScheduledThreadPoolExecutor; > import java.util.concurrent.TimeUnit; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > import ch.qos.logback.classic.LoggerContext; > import ch.qos.logback.classic.joran.JoranConfigurator; > import ch.qos.logback.core.joran.spi.JoranException; > public class Main extends Thread > { > private final static String LOGGER_CONFIGURATION_FILE = "logger.xml"; > private final Logger logger = LoggerFactory.getLogger(Main.class); > > private final long start; > > public Main() > throws JoranException > { > start = new Date().getTime(); > LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); > JoranConfigurator configurator = new JoranConfigurator(); > lc.shutdownAndReset(); > configurator.setContext(lc); > configurator.doConfigure(LOGGER_CONFIGURATION_FILE); > } > > public void start() > { > ScheduledThreadPoolExecutor ex1 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex2 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex3 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex4 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex5 = new ScheduledThreadPoolExecutor(1); > ex1.scheduleAtFixedRate(new Task("EX1"), 10, 10, TimeUnit.MICROSECONDS); > ex2.scheduleAtFixedRate(new Task("EX2"), 10, 10, TimeUnit.MICROSECONDS); > ex3.scheduleAtFixedRate(new Task("EX3"), 10, 10, TimeUnit.MICROSECONDS); > ex4.scheduleAtFixedRate(new Task("EX4"), 10, 10, TimeUnit.MICROSECONDS); > ex5.scheduleAtFixedRate(new Task("EX5"), 10, 10, TimeUnit.MICROSECONDS); > > super.start(); > } > > public void run() > { > try > { > while(true) > { > logger.debug("[MAIN] {}", new Date().getTime() - start); > Thread.sleep(10); > } > } > catch (InterruptedException e) > { > logger.info("[MAIN]: Interrupted: {}", e.getMessage()); > } > } > > public static void main(String[] args) > { > try > { > Main main = new Main(); > main.start(); > } > catch (JoranException e) > { > System.out.println("Failed to load application: " + e.getMessage()); > } > } > } > ------------------------------- > Task.java > ------------------------------- > import java.util.Date; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > public class Task implements Runnable > { > private final Logger logger = LoggerFactory.getLogger(Task.class); > private final Logger logger_main = LoggerFactory.getLogger(Main.class); > private final String name; > private final long start; > > public Task(final String name) > { > this.name = name; > start = new Date().getTime(); > } > public void run() > { > logger.debug("[{}] {}", name, new Date().getTime() - start); > logger_main.debug("[MAIN] - [{}] {}", name, new Date().getTime() - start); > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCORE-63) Deadlock when running on multiple core processors
by Ceki Gulcu (JIRA) 23 Mar '09

23 Mar '09

[ http://jira.qos.ch/browse/LBCORE-63?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-63: ---------------------------------- Hello Robert, Any progress on what exactly? This issue is related to logback console plug-in for eclipse as such as logback's threading model. Are you using the the logback console plug-in for eclipse? > Deadlock when running on multiple core processors > ------------------------------------------------- > > Key: LBCORE-63 > URL: http://jira.qos.ch/browse/LBCORE-63 > Project: logback-core > Issue Type: Sub-task > Affects Versions: 0.9.9 > Environment: Operating System: Windows > Platform: PC > Reporter: Toni Heimala > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: patch.txt, patch2.txt, patch3.txt > > > When you run logging into same file from many threads on a system that has more than one physical processor (Dual Core for example), a deadlock will occur after a while. This can not be reproduced on HyperThreading processors. Here's an example program that will demonstrate the behavior: > ----------------------------- > Main.java > ----------------------------- > import java.util.Date; > import java.util.concurrent.ScheduledThreadPoolExecutor; > import java.util.concurrent.TimeUnit; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > import ch.qos.logback.classic.LoggerContext; > import ch.qos.logback.classic.joran.JoranConfigurator; > import ch.qos.logback.core.joran.spi.JoranException; > public class Main extends Thread > { > private final static String LOGGER_CONFIGURATION_FILE = "logger.xml"; > private final Logger logger = LoggerFactory.getLogger(Main.class); > > private final long start; > > public Main() > throws JoranException > { > start = new Date().getTime(); > LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); > JoranConfigurator configurator = new JoranConfigurator(); > lc.shutdownAndReset(); > configurator.setContext(lc); > configurator.doConfigure(LOGGER_CONFIGURATION_FILE); > } > > public void start() > { > ScheduledThreadPoolExecutor ex1 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex2 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex3 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex4 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex5 = new ScheduledThreadPoolExecutor(1); > ex1.scheduleAtFixedRate(new Task("EX1"), 10, 10, TimeUnit.MICROSECONDS); > ex2.scheduleAtFixedRate(new Task("EX2"), 10, 10, TimeUnit.MICROSECONDS); > ex3.scheduleAtFixedRate(new Task("EX3"), 10, 10, TimeUnit.MICROSECONDS); > ex4.scheduleAtFixedRate(new Task("EX4"), 10, 10, TimeUnit.MICROSECONDS); > ex5.scheduleAtFixedRate(new Task("EX5"), 10, 10, TimeUnit.MICROSECONDS); > > super.start(); > } > > public void run() > { > try > { > while(true) > { > logger.debug("[MAIN] {}", new Date().getTime() - start); > Thread.sleep(10); > } > } > catch (InterruptedException e) > { > logger.info("[MAIN]: Interrupted: {}", e.getMessage()); > } > } > > public static void main(String[] args) > { > try > { > Main main = new Main(); > main.start(); > } > catch (JoranException e) > { > System.out.println("Failed to load application: " + e.getMessage()); > } > } > } > ------------------------------- > Task.java > ------------------------------- > import java.util.Date; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > public class Task implements Runnable > { > private final Logger logger = LoggerFactory.getLogger(Task.class); > private final Logger logger_main = LoggerFactory.getLogger(Main.class); > private final String name; > private final long start; > > public Task(final String name) > { > this.name = name; > start = new Date().getTime(); > } > public void run() > { > logger.debug("[{}] {}", name, new Date().getTime() - start); > logger_main.debug("[MAIN] - [{}] {}", name, new Date().getTime() - start); > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCORE-63) Deadlock when running on multiple core processors
by Robert Dale (JIRA) 23 Mar '09

23 Mar '09

[ http://jira.qos.ch/browse/LBCORE-63?page=com.atlassian.jira.plugin.system.i… ] Robert Dale commented on LBCORE-63: ----------------------------------- Any progress on this issue? I'm getting: java.lang.Thread.State: BLOCKED on ch.qos.logback.core.rolling.RollingFileAppender@2db3f4 owned by: http-127.0.0.1-8080-2 at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:66) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:393) at ch.qos.logback.classic.Logger.debug(Logger.java:500) Thanks. > Deadlock when running on multiple core processors > ------------------------------------------------- > > Key: LBCORE-63 > URL: http://jira.qos.ch/browse/LBCORE-63 > Project: logback-core > Issue Type: Sub-task > Affects Versions: 0.9.9 > Environment: Operating System: Windows > Platform: PC > Reporter: Toni Heimala > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: patch.txt, patch2.txt, patch3.txt > > > When you run logging into same file from many threads on a system that has more than one physical processor (Dual Core for example), a deadlock will occur after a while. This can not be reproduced on HyperThreading processors. Here's an example program that will demonstrate the behavior: > ----------------------------- > Main.java > ----------------------------- > import java.util.Date; > import java.util.concurrent.ScheduledThreadPoolExecutor; > import java.util.concurrent.TimeUnit; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > import ch.qos.logback.classic.LoggerContext; > import ch.qos.logback.classic.joran.JoranConfigurator; > import ch.qos.logback.core.joran.spi.JoranException; > public class Main extends Thread > { > private final static String LOGGER_CONFIGURATION_FILE = "logger.xml"; > private final Logger logger = LoggerFactory.getLogger(Main.class); > > private final long start; > > public Main() > throws JoranException > { > start = new Date().getTime(); > LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); > JoranConfigurator configurator = new JoranConfigurator(); > lc.shutdownAndReset(); > configurator.setContext(lc); > configurator.doConfigure(LOGGER_CONFIGURATION_FILE); > } > > public void start() > { > ScheduledThreadPoolExecutor ex1 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex2 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex3 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex4 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex5 = new ScheduledThreadPoolExecutor(1); > ex1.scheduleAtFixedRate(new Task("EX1"), 10, 10, TimeUnit.MICROSECONDS); > ex2.scheduleAtFixedRate(new Task("EX2"), 10, 10, TimeUnit.MICROSECONDS); > ex3.scheduleAtFixedRate(new Task("EX3"), 10, 10, TimeUnit.MICROSECONDS); > ex4.scheduleAtFixedRate(new Task("EX4"), 10, 10, TimeUnit.MICROSECONDS); > ex5.scheduleAtFixedRate(new Task("EX5"), 10, 10, TimeUnit.MICROSECONDS); > > super.start(); > } > > public void run() > { > try > { > while(true) > { > logger.debug("[MAIN] {}", new Date().getTime() - start); > Thread.sleep(10); > } > } > catch (InterruptedException e) > { > logger.info("[MAIN]: Interrupted: {}", e.getMessage()); > } > } > > public static void main(String[] args) > { > try > { > Main main = new Main(); > main.start(); > } > catch (JoranException e) > { > System.out.println("Failed to load application: " + e.getMessage()); > } > } > } > ------------------------------- > Task.java > ------------------------------- > import java.util.Date; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > public class Task implements Runnable > { > private final Logger logger = LoggerFactory.getLogger(Task.class); > private final Logger logger_main = LoggerFactory.getLogger(Main.class); > private final String name; > private final long start; > > public Task(final String name) > { > this.name = name; > start = new Date().getTime(); > } > public void run() > { > logger.debug("[{}] {}", name, new Date().getTime() - start); > logger_main.debug("[MAIN] - [{}] {}", name, new Date().getTime() - start); > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

Replacing CallerData class
by Ceki Gulcu 20 Mar '09

20 Mar '09

Hello, I would like to replace the CallerData class with StackTraceElement. The two classes contain the same fields. StackTraceElement is part of the JDK. I can think of no valid reason to duplicate a class found in the JDK. Comments/objections? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

5 17