March 2009 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-62) Dinimish contention among concurrent threads when using logback
by Ceki Gulcu (JIRA) 26 Jun '09

26 Jun '09

Dinimish contention among concurrent threads when using logback --------------------------------------------------------------- Key: LBCORE-62 URL: http://jira.qos.ch/browse/LBCORE-62 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.9 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.10 We should strive to diminish interference among concurrent threads when using logback. -- 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 1

[JIRA] Created: (LBCLASSIC-110) TargetLengthBasedClassNameAbbreviator does not work for strings with more than 12 dots (inclusive).
by Lukas Zapletal (JIRA) 22 Jun '09

22 Jun '09

TargetLengthBasedClassNameAbbreviator does not work for strings with more than 12 dots (inclusive). --------------------------------------------------------------------------------------------------- Key: LBCLASSIC-110 URL: http://jira.qos.ch/browse/LBCLASSIC-110 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.9, 0.9.10, 0.9.11, 0.9.12, 0.9.13, 0.9.14, 0.9.15 Reporter: Lukas Zapletal Assignee: Logback dev list Please add this to TargetLengthBasedClassNameAbbreviatorTest: System.out.println("13"); { // 13 dots test TargetLengthBasedClassNameAbbreviator abbreviator = new TargetLengthBasedClassNameAbbreviator(20); String name = "com.pike.test.puma.wm.isd2dita.core.g.project.server.pkg.isobjecttype.isobject.ISObjectContentGenerator"; assertEquals("c.p.t.p.w.i.c.g.o.s.r.i.ISObjectContentGenerator", abbreviator.abbreviate(name)); } System.out.println("12"); { // 12 dots test TargetLengthBasedClassNameAbbreviator abbreviator = new TargetLengthBasedClassNameAbbreviator(20); String name = "com.pike.puma.wm.isd2dita.core.g.project.server.pkg.isobjecttype.isobject.ISObjectContentGenerator"; assertEquals("c.p.p.w.i.c.g.o.s.r.i.ISObjectContentGenerator", abbreviator.abbreviate(name)); } Logs are disappearing when this bug occurs. It throws ArrayIndexOfBounds when testing but in production logs are just skipped (thus this bug is not FATAL-CRITICAL). Workaround: higher the 12 dot limit. Better workaround: handle with strings correctly not to ses AIOB exception ever. -- 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 3

[JIRA] Created: (LBGENERAL-27) 0.9.15 OSGi import package specification in the 0.9.15 zip files specify dependencies on 0.9 instead of 0.9.15
by aappddeevv (JIRA) 31 Mar '09

31 Mar '09

0.9.15 OSGi import package specification in the 0.9.15 zip files specify dependencies on 0.9 instead of 0.9.15 -------------------------------------------------------------------------------------------------------------- Key: LBGENERAL-27 URL: http://jira.qos.ch/browse/LBGENERAL-27 Project: logback-general Issue Type: Bug Components: build-structure Affects Versions: 0.9.15 Environment: OSGi Reporter: aappddeevv Assignee: Logback dev list The logback classic MF specifies import package dependencies of 0.9 on logback core packages. But in the 0.9.15 zip, the logback core is level 0.9.15. This makes bundle resolution difficult under Equinox OSGi. In the same release, it appears that both logback core and logback are running at 0.9.15 and the import-package specification in logback classic MF should probably also specify the same release level since both core and classic are tagged at 0.9.15 instead of 0.9 in the same zip file anyway. -- 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 1

[JIRA] Created: (LBCLASSIC-122) %contextName with HTMLLayout produces empty logfiles
by Rick Janda (JIRA) 30 Mar '09

30 Mar '09

%contextName with HTMLLayout produces empty logfiles ---------------------------------------------------- Key: LBCLASSIC-122 URL: http://jira.qos.ch/browse/LBCLASSIC-122 Project: logback-classic Issue Type: Bug Components: layout Affects Versions: 0.9.15 Reporter: Rick Janda Assignee: Logback dev list Hello Logback team, I encountered a unexpected behavior when trying to print out the log context name in the html output. I configured a FileAppender with the following layout: <layout class="ch.qos.logback.classic.html.HTMLLayout"> <Pattern>%d{HH:mm:ss.SSS}%mdc{refId}%contextName%msg</Pattern> </layout> With this pattern, non of the log messages end up in the file. The output completely stops after the table header. If I remove "%contextName" from the pattern, I get my log messages written to the file as expected. Could you please have a look at this issue. Thank you 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

[JIRA] Created: (LBGENERAL-26) Define taks for volunteers
by Ceki Gulcu (JIRA) 26 Mar '09

26 Mar '09

Define taks for volunteers -------------------------- Key: LBGENERAL-26 URL: http://jira.qos.ch/browse/LBGENERAL-26 Project: logback-general Issue Type: Improvement Reporter: Ceki Gulcu Assignee: Logback dev list Priority: Critical Fix For: 0.9.16 Create a web-page defining taks or areas of work for volunteers. -- 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

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