August 2008 - logback-dev - mailman3.qos.ch

[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: (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: (LBCORE-54) FileAppender to support FileNamePattern option
by Chris Cheshire (JIRA) 27 Oct '08

27 Oct '08

FileAppender to support FileNamePattern option ---------------------------------------------- Key: LBCORE-54 URL: http://jira.qos.ch/browse/LBCORE-54 Project: logback-core Issue Type: Improvement Components: Appender Environment: Any Reporter: Chris Cheshire Assignee: Logback dev list It would be very useful if the base FileAppender supported the FileNamePattern option, the same as the rolling policy classes do for the RollingFileAppender. This will allow for log files to be created directly into a date based directory in the format of "logs/yyyy/MM/dd/appname.log". -- 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 6

[JIRA] Created: (LBCLASSIC-53) Add MDC Level Filtering
by Ralph Goers (JIRA) 27 Oct '08

27 Oct '08

Add MDC Level Filtering ----------------------- Key: LBCLASSIC-53 URL: http://jira.qos.ch/browse/LBCLASSIC-53 Project: logback-classic Issue Type: New Feature Environment: All Reporter: Ralph Goers Assignee: Logback dev list Attachments: MDCLevelFilter.zip The company I work for is an Application Service Provider. Requests to the same software running in a single JVM might be on behalf of any one of these companies. In addition, our middle tier contains services that my be called from several different products and are run on behalf of a user of one of these companies. Operationally, we require the ability to be able to filter based on company, product, possibly the end user or several other criteria. The TurboFilter provided allows individual values for keys in the MDC to be associated with a logging level. So if the MDC contains a key for the company the TurboFilter can be configured with the name of the company and the corresponding logging level. So if CompanyA's level is set to debug while the default level is error, only debug events for CompanyA will be passed on. -- 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

4 10

[JIRA] Created: (LBCORE-55) getPresentationFooter and getFileFooter are swapped
by Natan Cox (JIRA) 17 Oct '08

17 Oct '08

getPresentationFooter and getFileFooter are swapped --------------------------------------------------- Key: LBCORE-55 URL: http://jira.qos.ch/browse/LBCORE-55 Project: logback-core Issue Type: Bug Components: Appender Reporter: Natan Cox Assignee: Logback dev list If I look into the code I can see in WriterAppender writeFooter String h = layout.getFileFooter(); if ((h != null) && (this.writer != null)) { try { this.writer.write(h); String pf = layout.getPresentationFooter(); if (pf != null) { this.writer.write(pf); } And if I look into HTMLLayoutBase I see getFileFooter => </body></html> getPresentationFooter => </table> which means we are first closing the HTML and then the TABLE? Fix: String pf = layout.getPresentationFooter(); if ((pf != null) && (this.writer != null)) { try { this.writer.write(pf); String h = layout.getFileFooter(); if (h != null) { this.writer.write(h); } -- 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