- logback-dev - mailman3.qos.ch

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.28-12-g1bdfa35
by git-noreply＠pixie.qos.ch 25 Feb '11

25 Feb '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 1bdfa357086917d16daec387ed398b4ee2fc802a (commit) from bcecc7d49ee26da3f402281cdc4e0d8f86fbd19b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=1bdfa357086917d16daec387… http://github.com/ceki/logback/commit/1bdfa357086917d16daec387ed398b4ee2fc8… commit 1bdfa357086917d16daec387ed398b4ee2fc802a Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Feb 25 18:07:18 2011 +0100 adding a logback related job announcement diff --git a/logback-site/src/site/pages/job.html b/logback-site/src/site/pages/job.html new file mode 100644 index 0000000..074d840 --- /dev/null +++ b/logback-site/src/site/pages/job.html @@ -0,0 +1,32 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> + <title>Logback Home</title> + <link rel="stylesheet" type="text/css" href="css/common.css" /> + <link rel="stylesheet" type="text/css" href="css/screen.css" media="screen" /> + <link rel="stylesheet" type="text/css" href="css/_print.css" media="print" /> + + </head> + <body> + <script type="text/javascript">prefix='';</script> + <script src="templates/header.js" type="text/javascript"></script> + <div id="left"> + <noscript>Please turn on Javascript to view this menu</noscript> + <script src="templates/left.js" type="text/javascript"></script> + </div> + + <div id="content"> + + <h2>Software Developer</h2> + + + <p></p> + <p></p> + + <script src="templates/footer.js" type="text/javascript"></script> + </div> + </body> +</html> \ No newline at end of file ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/job.html | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 logback-site/src/site/pages/job.html hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-198) Logback complains if logback.xml is in a jar
by Attila Király (JIRA) 23 Feb '11

23 Feb '11

Logback complains if logback.xml is in a jar -------------------------------------------- Key: LBCORE-198 URL: http://jira.qos.ch/browse/LBCORE-198 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.28 Reporter: Attila Király Assignee: Logback dev list Priority: Minor If logback.xml is not available as a file (for example it is in a jar in the lib folder of a webapp) logback logs an error during configuration. The reason is that in ch.qos.logback.core.joran.spi.ConfigurationWatchList.convertToFile(URL) method it tries to convert the url to file and if it fails it marks this as an error. Imho it should simply silently not do anything in this case. -- 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

Running the logback project as a commitocracy
by Ceki Gülcü 21 Feb '11

21 Feb '11

Hello all, I am considering running the logback project as a commitocracy. The idea is to settle non controversial questions by consensus. However, whenever a decision cannot be reached by unanimous agreement, a vote is called for. The commit-point for or against a motion are summed, the total accumulated commit-points determining the outcome. Developers earn one commit point per day for every day in which they commit code to the project. For git, the dvcs we use in logback, the following command computes the commit-points accumulated by Alice. git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l At present time, the commit-points for the logback project: Ceki Gulcu 486 commit-points Sebastien Pennec 164 commit-points Tomasz Nurkiewicz 10 commit-points A committocracy may be less efficient than the BDFL model for decision making, and compared to the Apache-way, it grants less power to newcomers. However, a committocracy is a fair system in the sense that the same rules apply to all. Today's committer with the most committer-points can be different than that of tomorrow. Moreover, compared to the Apache-way, a committocracy drastically reduces the risk of a project going haywire after admitting a new member. As a corollary, a project can safely reduce the wait-and-see period preceding the admission of new committers. Thus, newcomers may be granted committership status immediately (after their first commit). Your comments welcome. -- Ceki

5 17

LBCORE-147 - deletion of old RollingPolicy log files
by Greg Thomas 21 Feb '11

21 Feb '11

There's a ticket open at http://jira.qos.ch/browse/LBCORE-147 that is causing a problem for me; I'm willing to have a look at submitting a patch for this, along the lines of the suggestion I made in the ticket. I'll reproduce the comment I made here to save people looking ... Currently, if maxHistory=5 and the system is quiescent over the weekend so no logs are produced then ... 2011-02-17: Log file created (Thursday), log file for 2011-02-12 deleted if exists. 2011-02-18: Log file created (Friday), log file for 2011-02-13 deleted if exists. (2011-02-19: Saturday - No activity) (2011-02-20: Sunday - No activity) 2011-02-21: Log file created (Monday), log file for 2011-02-16 deleted if exists. This leaves the files for the 2011-02-14 and 2011-02-15 lying around. I'd suggest that a new optional setting is added, "maxHistoryGap" that indicates how far back the old log files should be deleted (default value=0). If set to 2 (to cope with weekends). This would result in ... 2011-02-17: Log file created (Thursday), log files for 2011-02-12, 2011-02-11, 2011-02-10 deleted if exists. 2011-02-18: Log file created (Friday), log files for 2011-02-13, 2011-02-12, 2011-02-11 deleted if exists. (2011-02-19: Saturday - No activity) (2011-02-20: Sunday - No activity) 2011-02-21: Log file created (Monday), log files for 2011-02-16, 2011-02-15, 2011-02-14 deleted if exists. Is there a better solution? Would I be wasting my time looking at this? Thanks, Greg

1 0

[JIRA] Created: (LBCORE-197) CSS Builder that can accept the css text directly
by Benoit Xhenseval (JIRA) 19 Feb '11

19 Feb '11

CSS Builder that can accept the css text directly ------------------------------------------------- Key: LBCORE-197 URL: http://jira.qos.ch/browse/LBCORE-197 Project: logback-core Issue Type: New Feature Reporter: Benoit Xhenseval Assignee: Logback dev list I suggest creating a CSSBuilder class that can accept the CSS text directly in the XML configuration file. We will submit a simple implementation. Thanks for 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

2 2

[JIRA] Created: (LBCLASSIC-252) Logback fails to load Groovy config when run under @Grab
by Evgeny Goldin (JIRA) 18 Feb '11

18 Feb '11

Logback fails to load Groovy config when run under @Grab -------------------------------------------------------- Key: LBCLASSIC-252 URL: http://jira.qos.ch/browse/LBCLASSIC-252 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Evgeny Goldin Assignee: Logback dev list Attachments: error.txt, logback.groovy *{{"ch.qos.logback.classic.gaffer.GafferConfigurator:48"}}* creates a GroovyShell() without specifying the classloader. When I have a Groovy application using Logback with Groovy config and it is retrieved with Groovy @Grab, where CL hierarchy is somewhat different from a usual invocation, the execution fails, error log is attached together with Groovy config. Here is the Groovy script using GCommons library that uses Logback: http://goo.gl/wuU05 Here is the patch that is now part of GCommons to make Logback load the config: http://goo.gl/pvSzz -- 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-195) TimeBasedRollingPolicy doesn't delegate life-cycle events
by Juergen Hermann (JIRA) 11 Feb '11

11 Feb '11

TimeBasedRollingPolicy doesn't delegate life-cycle events --------------------------------------------------------- Key: LBCORE-195 URL: http://jira.qos.ch/browse/LBCORE-195 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.27 Environment: Bug is also in the GIT head revision. Reporter: Juergen Hermann Assignee: Logback dev list In ch.qos.logback.core.rolling, both TimeBasedRollingPolicy and TimeBasedFileNamingAndTriggeringPolicy support the LifeCycle interface, and the former aggregates the latter. What TimeBasedRollingPolicy fails to do is to delegate the stop() event to its timeBasedFileNamingAndTriggeringPolicy object (it actually has no own stop() currently). This causes resource management problems in my use case, because my stop() is never called. Fix: Add this to ./logback-core/src/main/java/ch/qos/logback/core/rolling/TimeBasedRollingPolicy.java {noformat} /** * {@inheritDoc} */ @Override public void stop() { if (timeBasedFileNamingAndTriggeringPolicy != null) { timeBasedFileNamingAndTriggeringPolicy.stop(); } super.stop(); } {noformat} -- 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-251) LoggingEventVO failed to serialize when argument toString() throws exception
by Eugen (JIRA) 11 Feb '11

11 Feb '11

LoggingEventVO failed to serialize when argument toString() throws exception ----------------------------------------------------------------------------- Key: LBCLASSIC-251 URL: http://jira.qos.ch/browse/LBCLASSIC-251 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.26 Reporter: Eugen Assignee: Logback dev list LoggingEventVO.writeObject() don't handle situation when argument toString() throws exception. LoggingEventVO become only serialized to OutputStream partiality, and deserialization failed with exception java.lang.ArrayStoreException: ch.qos.logback.classic.spi.LoggingEventVO at ch.qos.logback.classic.spi.LoggingEventVO.readObject(LoggingEventVO.java:190) ~[logback-classic-0.9.26.jar:na] Suppose same fail-safe behavior required as in MessageFormatter.safeObjectAppend -- 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: (LBGENERAL-37) Need to scan included files
by lala (JIRA) 10 Feb '11

10 Feb '11

Need to scan included files --------------------------- Key: LBGENERAL-37 URL: http://jira.qos.ch/browse/LBGENERAL-37 Project: logback-general Issue Type: New Feature Reporter: lala Assignee: Logback dev list Priority: Minor I'm using the following configuration and I'm looking for a method to scan included files. <configuration scan="true" scanPeriod="10 seconds"> <insertFromJNDI env-entry-name="java:comp/env/logback-file" as="logback-file" /> <contextName>lala</contextName> <include file="${logback-file}" /> </configuration> Once scan directive is used, logback is going to rescan this file every 10 seconds whether its modification date has changed. The issue is that I have to overwrite the previous file in order to rescan the target ${logback-file}. I suggest adding an attribute in the configuration marker in order to force logback to scan included files . It could be something like that: <configuration scan="true" scanPeriod="10 seconds" scanIncluded="true"> ..... </configuration> In order to process this task, at each scan logback should memorize the reference to the included files, and their latest modification date. Consequently, every 10 seconds, logback check the whole list of files and rescan the main file if something has changed. -- 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 5

[JIRA] Created: (LBCLASSIC-227) HOSTNAME property not resolved
by Simon Kelly (JIRA) 10 Feb '11

10 Feb '11

HOSTNAME property not resolved ------------------------------ Key: LBCLASSIC-227 URL: http://jira.qos.ch/browse/LBCLASSIC-227 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.26 Reporter: Simon Kelly Assignee: Logback dev list When using the hostname property the following ERROR message is logged: Appender [EMAIL] of type [ch.qos.logback.classic.net.SMTPAppender] has no appplicable [HOSTNAME] property Configuration as below: ======================================================= import ch.qos.logback.classic.encoder.PatternLayoutEncoder import ch.qos.logback.core.ConsoleAppender import ch.qos.logback.classic.net.SMTPAppender import ch.qos.logback.core.status.OnConsoleStatusListener import ch.qos.logback.classic.PatternLayout import ch.qos.logback.classic.html.HTMLLayout import static ch.qos.logback.classic.Level.TRACE import static ch.qos.logback.classic.Level.DEBUG import static ch.qos.logback.classic.Level.INFO import static ch.qos.logback.classic.Level.WARN import static ch.qos.logback.classic.Level.ERROR statusListener(OnConsoleStatusListener) def appenderList = ["Console"] def enable_email = true if(enable_email) { appender("EMAIL", SMTPAppender) { SMTPHost = "smtp.gmail.com" SMTPPort = 587 STARTTLS = true username = "username" password = "password" to = "to(a)demo.com" from = "from(a)demo.com" subject = "ERROR from ${HOSTNAME}: %logger{20} - %m" layout(HTMLLayout) { pattern = "%d{HH:mm:ss.SSS}%thread%-5level%logger{36}%msg" } } appenderList.add("EMAIL") } appender("Console", ConsoleAppender) { encoder(PatternLayoutEncoder) { pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" } } logger("org.celllife", INFO) scan("30 seconds") root(ERROR, ["Console", "EMAIL"]) -- 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