January 2009 - 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: (CONSPLUG-16) Make the Consol plugin available via an update site
by Szel Zoltan (JIRA) 28 Aug '12

28 Aug '12

Make the Consol plugin available via an update site --------------------------------------------------- Key: CONSPLUG-16 URL: http://jira.qos.ch/browse/CONSPLUG-16 Project: Console Plugin Issue Type: Task Components: other Reporter: Szel Zoltan Assignee: Logback dev list Hi, making the Consol plugin available via an Update Site would make the install of the plugin much easier for developers. Please consider creating one for this very useful plugin. Thanks in advance! Best Regardsm 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

4 6

[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: (LBCLASSIC-74) NullPointerException in Logger after container restart
by Manel Clos (JIRA) 11 Jun '12

11 Jun '12

NullPointerException in Logger after container restart ------------------------------------------------------ Key: LBCLASSIC-74 URL: http://jira.qos.ch/browse/LBCLASSIC-74 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.9 Environment: Eclipse 3.4, Java 5, Tomcat 5.5.26, plain JSP (no servlet) Reporter: Manel Clos Assignee: Logback dev list Hi, loggerContext in the Logger class is null after container restart. This will produce a NPE when trying to further use logback. java.lang.NullPointerException at ch.qos.logback.classic.Logger.callTurboFilters(Logger.java:775) at ch.qos.logback.classic.Logger.isDebugEnabled(Logger.java:630) at ch.qos.logback.classic.Logger.isDebugEnabled(Logger.java:613) at test.LogbackTest.testLogger(LogbackTest.java:15) -- 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 8

[JIRA] Created: (LBCORE-84) Typo in PropertyAction
by Michael Franz (JIRA) 24 Apr '12

24 Apr '12

Typo in PropertyAction ---------------------- Key: LBCORE-84 URL: http://jira.qos.ch/browse/LBCORE-84 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.14 Reporter: Michael Franz Assignee: Logback dev list Priority: Trivial The following message is printed |-WARN in ch.qos.logback.core.joran.action.PropertyAction - [substitutionProperty] element has been deprecated. Plase use the [property] element instead. There an 'e' missing in "Please". -- 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: (LBCORE-79) FixedWindowRollingPolicy performs compression on the logging thread
by Szel Zoltan (JIRA) 02 Sep '11

02 Sep '11

FixedWindowRollingPolicy performs compression on the logging thread ------------------------------------------------------------------- Key: LBCORE-79 URL: http://jira.qos.ch/browse/LBCORE-79 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: 0.9.13 Reporter: Szel Zoltan Assignee: Logback dev list Hi, the FixedWindowRollingPolicy performs the compression on the logging thread which can bring the application to halt, when compressing large files. Please consider modifing the FixedWindowRollingPolicy to perform the operation on a background thread as requested in LBCORE-48. 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 2

[JIRA] Created: (LBCLASSIC-82) Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output
by Robert Elliot (JIRA) 20 May '11

20 May '11

Allow an Appender to be added to a Logger with a Level for more fine grained control of logging output ------------------------------------------------------------------------------------------------------ Key: LBCLASSIC-82 URL: http://jira.qos.ch/browse/LBCLASSIC-82 Project: logback-classic Issue Type: New Feature Components: appender, joran Environment: N/A Reporter: Robert Elliot Assignee: Logback dev list Priority: Minor Here's my use case: I have an appender, standard.log, whose job is to log major system events such as startup and shutdown, and all problems. I have configured my logger levels very carefully to ensure I get exactly the output I want - in some cases suppressing WARN messages that I know are not a problem by setting the level to ERROR, in some cases allowing INFO messages that let me see important lifecycle events. A simplified example might look like this: root=WARN,standard.log x.y=INFO a=ERROR I have a problem in a couple of parts of the system which means I want to turn on debug logging for that part of the system. I want the output of this to go to a separate appender - debug.log. So now my config looks like this: root=WARN,standard.log x.y=INFO x.y.z=DEBUG,debug.log a=ERROR a.b=DEBUG,debug.log But now I have an issue; all my debug statements are going to standard.log. It is being polluted with a load of information I don't want in it. I have several options: 1) Set additivity to false on x.y.z and a.b. But then any ERROR messages in a.b or INFO or above messages in x.y.z no longer get to standard.log, so this won't do 2) Add a filter of INFO or greater to the standard.log appender But then any INFO and WARN messages in a.b will get to standard.log - and I only want ERROR messages from a and its descendants in there 3) Add a filter of WARN or greater to the standard.log appender Now I still get the WARN messages from a.b that I don't want - and I've lost the INFO messages from x.y that I do want 4) Create two new appenders, standard.log2 for a and standard.log3 for x.y.z. Add a filter to standard.log2 so that it only accepts ERROR. Add a filter to standard.log3 so it only accepts INFO or above. Set additivity to false on a and x.y.z. That works. But it's a huge amount of added configuration, and that would rapidly multiply in a real world setting. 5) Create a custom filter for standard.log which would effectively mirror the logger config by querying the event for its logger and and level. That blows DRY out of the water, of course, and again is a large amount of work for a simple use case. My suggestion to make this easy is to allow Appenders to be added to a Logger with a Level. This solution would operate in parallel with the existing solution, and would not alter the existing behaviour one iota. This would allow me to add debug,log as an appender on a and x.y.z with a level of debug. All debug statements in a and x.y.z & their descendants would be appended to that appender. All statements would also be passed to the "normal" appender and logger hierarchy, so standard.log would still get the same output as before. I have written unit tests for this behaviour and attach a patch fulfilling them; I hope the unit tests flesh out any queries you may have around how this behaves in edge cases. The only change to the public API is a new method addAppender(Appender<LoggingEvent> newAppender, Level level) on Logger. The only change to the config format is allowing an optional level attribute on appender-ref. -- 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-102) Suggestion: Change logger name of inner classes.
by Joern Huxhorn (JIRA) 15 Dec '09

15 Dec '09

Suggestion: Change logger name of inner classes. ------------------------------------------------ Key: LBCLASSIC-102 URL: http://jira.qos.ch/browse/LBCLASSIC-102 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Logback dev list At the moment, the logger name of inner classes is OuterClass$InnerClass. Because of that, the logging level of OuterClass isn't inherited by InnerClass at the moment. If LoggerFactory changed the logger name to OuterClass.InnerClass instead, InnerClass would inherit the logging level of OuterClass which seems intuitively correct. I'd suggest to accept both $InnerClass and .InnerClass style in logback configurations for compatibility and usability reasons. -- 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 14

[JIRA] Created: (LBCLASSIC-101) Problem with logback OSGi bundles
by Ceki Gulcu (JIRA) 03 Dec '09

03 Dec '09

Problem with logback OSGi bundles --------------------------------- Key: LBCLASSIC-101 URL: http://jira.qos.ch/browse/LBCLASSIC-101 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.14 Reporter: Ceki Gulcu Assignee: Logback dev list Priority: Critical http://www.slf4j.org/pipermail/user/2009-January/000661.html http://www.slf4j.org/pipermail/user/2009-January/000663.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

2 3

[JIRA] Created: (LBCORE-76) Joran patterns should be case insensitive
by Ceki Gulcu (JIRA) 09 Aug '09

09 Aug '09

Joran patterns should be case insensitive ----------------------------------------- Key: LBCORE-76 URL: http://jira.qos.ch/browse/LBCORE-76 Project: logback-core Issue Type: Improvement Components: Joran Affects Versions: 0.9.12 Reporter: Ceki Gulcu Assignee: Logback dev list At present time, joran patterns are case sensitive. However, implicit actions are case insensitive. For coherence, joran patterns should be case insensitive. -- 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 3