September 2008 - logback-dev

[JIRA] Created: (LBCORE-52) Make SyslogAppenderBase fields protected
by Anton Tagunov (JIRA) 27 Dec '12

27 Dec '12

Make SyslogAppenderBase fields protected ---------------------------------------- Key: LBCORE-52 URL: http://jira.qos.ch/browse/LBCORE-52 Project: logback-core Issue Type: Improvement Reporter: Anton Tagunov Assignee: Logback dev list Hi! We'd like to customize some of SyslogAppender. Since SyslogAppenderBase class is public and is a base class by destination would it be appropriate to have all of the fields be designated as 'protected'? -- 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

3 5

[JIRA] Created: (LBCLASSIC-52) Allow multiple addresses for "to" property of SMTPAppender
by JIRA Administrator (JIRA) 11 Jul '12

11 Jul '12

Allow multiple addresses for "to" property of SMTPAppender ---------------------------------------------------------- Key: LBCLASSIC-52 URL: http://jira.qos.ch/browse/LBCLASSIC-52 Project: logback-classic Issue Type: Improvement Reporter: Andrey Utkin Assignee: Ceki Gulcu SMTPAppender don`t allow to specify multiple addresses in single "to" property. So that, it is (almost?) impossible to specify multiple "to" addresses via variable substitution. We should know exact number of addresses (variables) to specify appropriate quantity of <to> elements. But number of "to" addresses could be changed during application using and differ from customer to customer. So, IMFO it will be helpful to allow specifying multiple addresses in one <to> element. Multiple addresses could be separated by comma, for example (as comma is not valid character for email address). Right now we are using simple workaround. We subclass SMTPAppender and overwrite addTo(): {code} @Override public void addTo(String to) { StringTokenizer st = new StringTokenizer(to, ","); while(st.hasMoreTokens()) { super.addTo(st.nextToken().trim()); } } {code} This solution works just fine for us. May be it will be good to include this feature in core logback too. -- 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

3 6

[JIRA] Created: (LBCORE-51) LoggerFactory doesnt respect custom ContextSelector
by Paul Gregoire (JIRA) 28 Dec '08

28 Dec '08

LoggerFactory doesnt respect custom ContextSelector --------------------------------------------------- Key: LBCORE-51 URL: http://jira.qos.ch/browse/LBCORE-51 Project: logback-core Issue Type: Bug Environment: Windows XP64, Java 6, Red5 v0.7.1-dev, Logback 0.9.9, Slf4j 1.5.0 Reporter: Paul Gregoire Assignee: Logback dev list I have found that calling LoggerFactory.getLogger(xxxx) does not make calls to my custom context selector. I expect to see a call to getLoggerContext() but I dont. Do I need to create my own LoggerFactory impl to get my web context apps and red5 apps to use their own Loggers? Main Red5 trunk (dev) http://svn1.cvsdude.com/osflash/red5/java/server/trunk/ My logger implementations http://svn1.cvsdude.com/osflash/red5/java/server/trunk/src/org/red5/logging/ Example JSP I used to test the log context selection <%@page import="org.slf4j.Logger,org.slf4j.LoggerFactory,org.slf4j.impl.StaticLoggerBinder,ch.qos.logback.classic.LoggerContext,org.red5.logging.LoggingContextSelector"%> <html> <body> <% // Logger log = LoggerFactory.getLogger("TestJsp"); log.info("This is a test log entry from a web context"); // LoggingContextSelector selector = (LoggingContextSelector) StaticLoggerBinder.SINGLETON.getContextSelector(); LoggerContext ctx = selector.getLoggerContext(mywebappcontextname); Logger log2 = ctx.getLogger("TestJsp"); log2.info("This is a test log entry from a web context attempt 2"); %> </body> </html> The first log goes to the "default" logger context and the second goes to the correct one. I also implemented the Servlet filter and context listener for this tested context. Anything I can do to help, please let me know.. I am getting extremely frustrated with this logging stuff and I'm sure our users are as well. -- 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 13

[JIRA] Created: (LBCLASSIC-73) LevelFilter should not match exact filter, but greaterOrEqual
by Bruno Navert (JIRA) 03 Dec '08

03 Dec '08

LevelFilter should not match exact filter, but greaterOrEqual ------------------------------------------------------------- Key: LBCLASSIC-73 URL: http://jira.qos.ch/browse/LBCLASSIC-73 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.9 Reporter: Bruno Navert Assignee: Logback dev list Priority: Minor LevelFilter currently matches EXACT level, it would be useful to match on greaterOrEqual instead. This would allow setting filter to DEBUG for instance, and it would allow INFO,ERROR etc through -- 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-22) problem converting log4j.properties file
by Ceki Gulcu (JIRA) 02 Dec '08

02 Dec '08

problem converting log4j.properties file ---------------------------------------- Key: LBGENERAL-22 URL: http://jira.qos.ch/browse/LBGENERAL-22 Project: logback-general Issue Type: Bug Reporter: Ceki Gulcu Assignee: Logback dev list Rob Ross wrote: I have a few comments for you. First, the log4j properties translator ( http://logback.qos.ch/translator/Welcome.do ) does not quite work. Maybe it's based on an old version and is now out of date, but you should think about updating it. The file it produced did not translate my properties that I used in log4j.properties to specify the log file path into the equivalent substitutionProperty elements, and it did not translate the Levels I had set on the log4j appenders. It did wrap them in Threshold elements, but the current XML schema wants these specified in a "filter" element on the appender. Also, it did not translate the settings for the rolling file appender into the FileNamePattern element. However, the Joran configurator gave me detailed enough Exception messages that it was easy to determine what the problems were and fix them. ref: http://www.qos.ch/pipermail/logback-user/2008-July/000492.html -- 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 2

Least-effort logging with bytecode modification
by Ramon Nogueira 18 Nov '08

18 Nov '08

Hi At the company I work for we use the same logging pattern almost everywhere, for example: public class SomeClass { private static final Logger log = LoggerFactory.getLogger(SomeClass.class); public void someMethod() { log.debug("A log message"); } } I would like to simplify this to: import static logging.LogApi.*; public class SomeClass { private void someMethod(String someArg) { debug("A log message"); // from static import } } And then have code equivalent to the former generated (preferably at class load time) dynamically. This could save us hundreds of lines of boilerplate code and provide other interesting options like declarative rules regarding the "injected" logger name, perhaps through class/method annotations and pre-calculating the source location information. I thought of implementing this with AspectJ but its probably easier to just use ASM directly for such a simple case. Any ideas/suggestions/precedents? Thanks Ramon

9 22

[JIRA] Created: (LBCLASSIC-61) JMXConfigurationAction should allow a configurable ObjectName.
by Anders Engström (JIRA) 07 Nov '08

07 Nov '08

JMXConfigurationAction should allow a configurable ObjectName. -------------------------------------------------------------- Key: LBCLASSIC-61 URL: http://jira.qos.ch/browse/LBCLASSIC-61 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.9 Reporter: Anders Engström Assignee: Logback dev list Currently there is no way to customize the ObjectName the MBean is bound to (besides using a ContextSelector - which can be a hassle). This is an issue when deploying several applications in the same JVM (read: multiple web-applications in the same servlet engine). This patch modifies JMXConfiguratorAction to accept two additional attributes that allow customizing the ObjectName for the MBean: <jmxConfigurator/> This yields the default ObjectName of "ch.qos.logback.classic:Name=${nameOfContext},Type=ch.qos.logback.classic.jmx.Configurator". <jmxConfigurator namespace="foo"/> This results in "ch.qos.logback.classic:Name=${nameOfContext},Type=ch.qos.logback.classic.jmx.Configurator,Namespace=foo". <jmxConfigurator objectName="logback:name=foo,type=bar"/> Which obviously results in "logback:name=foo,type=bar" :) Let me know if I need to adjust the patch in any way. -- 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: (LBCLASSIC-59) LogbackErrorListener
by Anton Tagunov (JIRA) 29 Oct '08

29 Oct '08

LogbackErrorListener -------------------- Key: LBCLASSIC-59 URL: http://jira.qos.ch/browse/LBCLASSIC-59 Project: logback-classic Issue Type: Improvement Reporter: Anton Tagunov Assignee: Logback dev list Priority: Minor Presently we can only poll StatusManager for errors. It would be nice to be able to subscribe to these messages. One idea was to allow custom StatusManager implementations. This sounds like a nice and sane idea in its own right. However I feel that providing subscription to error events and allowing users to provide alternative StatusManager implementations are orthogonal concerns. In fact I feel that application should be able to subscribe to logback errors no matter what StatusManager is used stock or custom. In other words I suggest it to be part of StatusManager interface/contract to provide subscriptions. Which brings me back to the idea that it would be best to provide subscription (listener) facility in the standards StatusManager. On yet another account http://jira.qos.ch/browse/LBCLASSIC-58 may be enough for most practical users. And I suspect that the most common LogbackErrorListener implementation will simply log to System.out. In any case we badly need to get these errors out of Logback. BTW an alternative implemenation of LogbackListener might log to a file. -- 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

5 5

[JIRA] Created: (LBCLASSIC-69) LevelToSyslogSeverity mistreating TRACE level
by Anton Tagunov (JIRA) 29 Oct '08

29 Oct '08

LevelToSyslogSeverity mistreating TRACE level --------------------------------------------- Key: LBCLASSIC-69 URL: http://jira.qos.ch/browse/LBCLASSIC-69 Project: logback-classic Issue Type: Bug Components: layout Affects Versions: 0.9.10 Reporter: Anton Tagunov Assignee: Logback dev list Hello, ch.qos.logback.classic.util.LevelToSyslogSeverity.convert() doesn't have a case for TRACE level. The result is this exception: This results in the following exception java.lang.IllegalArgumentException: Level TRACE is not a valid level for a printing method at ch.qos.logback.classic.util.LevelToSyslogSeverity.convert(LevelToSyslogSeverity.java:38) -- 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 1

[JIRA] Created: (LBCLASSIC-70) Let the LogbackMDCAdapter exhibit a full copy on write semantics
by Szel Zoltan (JIRA) 29 Oct '08

29 Oct '08

Let the LogbackMDCAdapter exhibit a full copy on write semantics ---------------------------------------------------------------- Key: LBCLASSIC-70 URL: http://jira.qos.ch/browse/LBCLASSIC-70 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.9, 0.9.10 Reporter: Szel Zoltan Assignee: Logback dev list Hi, I have implemented an async appender and i was very happy seeing that most of the methods of the MDCAdapter exhibits copy on write semantics. This is very handy in this scenerio, it helps to transfer the MDC map onto the background thread. But i have noticed, that the clear and setContextMap methods are breaking this semantics. Is there any chance in the next release to change the implementation of the clear and setContextMap to conform with cow? Thanks very much. P.S.: We are waiting for legal approval to contribute our appender implementation back to the community. Best Regards, Zoltan Szel -- 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 4