February 2014 - slf4j-dev - mailman3.qos.ch

[Bug 201] New: Need ability to shutdown loggers and flush appenders
by bugzilla-daemon＠pixie.qos.ch 03 Mar '15

03 Mar '15

http://bugzilla.slf4j.org/show_bug.cgi?id=201 Summary: Need ability to shutdown loggers and flush appenders Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: mike.schall(a)gmail.com There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); For logback it would call - loggerContext.stop() Other back ends - ??? This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. Discussion about this is happening on the user list at - http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 18

[Bug 241] New: LoggerWrapper doesn't fully support Bug 70
by bugzilla-daemon＠pixie.qos.ch 12 Nov '14

12 Nov '14

http://bugzilla.slf4j.org/show_bug.cgi?id=241 Summary: LoggerWrapper doesn't fully support Bug 70 Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Mac OS X 10.3 Status: NEW Severity: blocker Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: git(a)netcc.us Most methods in LoggerWrapper don't forward Throwables to the wrapped Logger per bug 70. Patch available at https://github.com/ceki/slf4j/pull/7 -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 2

[Bug 266] New: Memory Leak: Clearing MDC context with Log4J
by bugzilla-daemon＠qos.ch 25 Sep '14

25 Sep '14

http://bugzilla.slf4j.org/show_bug.cgi?id=266 Summary: Memory Leak: Clearing MDC context with Log4J Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: f.bantner(a)axon-e.de Recently after a long time log4j got it's problem with clearing the MDC context and the underlying ThreadLocal Hashmap fixed. S. https://issues.apache.org/bugzilla/show_bug.cgi?id=50486 This fixed a long running Problem with Tomcat freeing memory on reload. In order to do so, log4j's MDC got the clear method with 1.2.16 and with 1.2.17 fixed it so that it works. Log4j has an MDC adaptor for Log4J and it's own clear method. But instead of calling Log4J's clear it implements essentially (MDC.getContext()).clear() which only clears the HashMap but doesn't remove it from the ThreadLocal context resulting in a MemroryLeak. Short workaround: Instead of calling slf4j's MDC.clear() call log4j's MDC.clear() (but that is the exact opositit of what slf4j is made for) Simple Fix: change log4j's mdc adaptor to call MDC.clear() instead of MDC.getContext().clear(). More complex fix: If backward compatibility is an issue (like it was für log4j) than log4js solution can be applied here: Instead of calling MDC.clear() directly call it via reflexion if it exists and otherwise keep calling MDC.getContext().clear(). -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 3

[Bug 312] New: org.apache.log4j.Category need remove appender method
by bugzilla-daemon＠qos.ch 12 Mar '14

12 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=312 Priority: P5 Bug ID: 312 Assignee: slf4j-dev(a)qos.ch Summary: org.apache.log4j.Category need remove appender method Severity: enhancement Classification: Unclassified OS: Windows XP Reporter: wwaver(a)163.com Hardware: PC Status: NEW Version: 1.7.x Component: log4j-over-slf4j Product: SLF4J for dependency jar may contain below code: logger.removeAllAppenders() so please add all method of log4j.Category. thanks -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 176] New: Initialization (getILoggerFactory) is not thread safe
by bugzilla-daemon＠pixie.qos.ch 07 Mar '14

07 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=176 Summary: Initialization (getILoggerFactory) is not thread safe Product: SLF4J Version: 1.5.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: rcogswell(a)datasltn.com If a getLogger call occurs during initialization from a thread other than the one that triggered the initialization, it is treated the same as if it were a re-entrant call from the initialization thread (i.e. getILoggerFactory returns the TEMP_FACTORY). Scenario: 1. An SLF4J LogFactory.getLogger statement is at the beginning of a worker thread class's run method. 2. Two or more worker threads are started at the same time during server startup. 3. Since the getLogger statements from the workers are executed nearly simultaneously, the first one triggers the SLF4J initialization and subsequent workers receive NOPLogger instances from the TEMP_FACTORY since LoggerFactory.INITIALIZATION_STATE == ONGOING_INITILIZATION. 4. Logging then works successfully for the worker that triggered the initialization, but the logging for all other workers is suppressed. The only reason I've indicated the severity as "major" instead of "critical" is that I happen to have my own wrapper class around SLF4J, so it was easy for me to independently track whether or not SLF4J has been called and introduce appropriate synchronization around the first call. For those using SLF4J directly (as recommended), there would not likely be any straightforward workaround. Below I've included a new implementation for LoggerFactory.getILoggerFactory to address this. The key aspects of this new implementation are as follows: 1. Checks first for successful initialization since this is the case for which performance matters most. 2. Synchronizes around determining whether or not the current thread should perform initialization, but does not synchronize around the initialization itself. 3. Retains the previous behavior for re-entrant calls from the thread performing the initialization. 4. Calls from other threads during initialization will wait up to 10 seconds for the initialization to finish. The main downsides of the implementation below (aside from not yet being tested): 1. If a logging implementation uses multiple threads to perform its initialization and one of those threads does a getLogger call, then this change would have undesirable effects, but I would be very surprised if any SLF4J implementations have multi-threaded initialization. 2. 10 seconds was a fairly arbitrary choice. It might be worthwhile to allow this to be controlled by a system property with a default of 10 seconds. 3. Considerably more complicated than the current implementation. private static Thread INITIALIZATION_THREAD = null; private static Object INITIALIZATION_SYNCH = new Object(); /** * Return the {@link ILoggerFactory} instance in use. * * <p> * ILoggerFactory instance is bound with this class at compile time. * * @return the ILoggerFactory instance in use */ public static ILoggerFactory getILoggerFactory() { if (INITIALIZATION_STATE == SUCCESSFUL_INITILIZATION) { return getSingleton().getLoggerFactory(); } if (INITIALIZATION_STATE == FAILED_INITILIZATION) { throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG); } boolean shouldPerformInitialization = false; synchronized (INITIALIZATION_SYNCH) { if (INITIALIZATION_STATE == UNINITIALIZED) { INITIALIZATION_STATE = ONGOING_INITILIZATION; INITIALIZATION_THREAD = Thread.currentThread(); shouldPerformInitialization = true; } else if (INITIALIZATION_STATE == ONGOING_INITILIZATION) { if (Thread.currentThread() == INITIALIZATION_THREAD) { // support re-entrant behavior. // See also http://bugzilla.slf4j.org/show_bug.cgi?id=106 return TEMP_FACTORY; } try { INITIALIZATION_SYNCH.wait(10000); } catch (InterruptedException e) { Util.reportFailure("Initialization failed to complete within 10 seconds."); return TEMP_FACTORY; } } } if (shouldPerformInitialization) { performInitialization(); synchronized (INITIALIZATION_SYNCH) { INITIALIZATION_THREAD = null; INITIALIZATION_SYNCH.notifyAll(); } } switch (INITIALIZATION_STATE) { case SUCCESSFUL_INITILIZATION: return getSingleton().getLoggerFactory(); case FAILED_INITILIZATION: throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG); } throw new IllegalStateException("Unreachable code"); } -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 31

[Bug 314] New: Add bundle and sr information to MDC
by bugzilla-daemon＠qos.ch 28 Feb '14

28 Feb '14

http://bugzilla.slf4j.org/show_bug.cgi?id=314 Priority: P5 Bug ID: 314 Assignee: slf4j-dev(a)qos.ch Summary: Add bundle and sr information to MDC Severity: enhancement Classification: Unclassified OS: Linux Reporter: mail(a)laeubi-soft.de Hardware: PC Status: NEW Version: 1.7.x Component: osgi-over-slf4j Product: SLF4J It would be nice to have the bundle, version and ServiceReference information in the MDC context avaiable. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 313] New: binary compatibility broken from 1.6.4 to 1.6.6
by bugzilla-daemon＠qos.ch 28 Feb '14

28 Feb '14

http://bugzilla.slf4j.org/show_bug.cgi?id=313 Priority: P5 Bug ID: 313 Assignee: slf4j-dev(a)qos.ch Summary: binary compatibility broken from 1.6.4 to 1.6.6 Severity: enhancement Classification: Unclassified OS: Linux Reporter: tycho.lamerigts(a)imc.nl Hardware: PC Status: NEW Version: 1.6.x Component: Core API Product: SLF4J Several LoggerFactory static fields with INITIALIZATION in the name had their spelling corrected in slf4j-api version 1.6.6. Because the fields are not private but have default access, this constitutes a breach of binary compatibility (see Java Language Specification, section 13.4.8). In theory, somebody could have written code in the org.slf4j package that relies on these fields. It would be good if this binary incompatibility could be documented in the FAQ, which now incorrectly states that binary compatibility to date has never been broken. There are still many libraries out there that use 1.6.x versions. I have a build system that automatically checks for binary compatibility conflicts. It reported this one and I wasted some time finding the root cause and white-listing this conflict. It would have saved me time if this had been documented in the FAQ. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[qos-ch/slf4j] 3e7077: add missing file
by Ceki Gulcu 23 Feb '14

23 Feb '14

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 3e7077c27650bc041b30e5a237c436572f5e2ac8 https://github.com/qos-ch/slf4j/commit/3e7077c27650bc041b30e5a237c436572f5e… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2014-02-23 (Sun, 23 Feb 2014) Changed paths: A slf4j-migrator/src/test/java/org/slf4j/migrator/line/TrivialMatcher.java Log Message: ----------- add missing file

1 0

[qos-ch/slf4j] 49fcb6: Changing compiler version to 1.5
by Ceki Gulcu 23 Feb '14

23 Feb '14

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 49fcb62f02b6c4a6a8f71377885ec5d50c43673a https://github.com/qos-ch/slf4j/commit/49fcb62f02b6c4a6a8f71377885ec5d50c43… Author: Otávio Garcia <otavio(a)otavio.com.br> Date: 2014-02-23 (Sun, 23 Feb 2014) Changed paths: M jul-to-slf4j/pom.xml Log Message: ----------- Changing compiler version to 1.5 Commit: f59cd31a36b6faa87c6e1169f23219e3749459e5 https://github.com/qos-ch/slf4j/commit/f59cd31a36b6faa87c6e1169f23219e37494… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2014-02-23 (Sun, 23 Feb 2014) Changed paths: M jul-to-slf4j/pom.xml Log Message: ----------- Merge pull request #63 from garcia-jj/ot-jultoslf4j-jdk5 Changing compiler version to 1.5 for jul-to-slf4j Compare: https://github.com/qos-ch/slf4j/compare/f420e0255ff4...f59cd31a36b6

1 0

[qos-ch/slf4j] f420e0: mention Otavio Garcia
by Ceki Gulcu 23 Feb '14

23 Feb '14

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: f420e0255ff44bf30a07c6787a86a02b635558bc https://github.com/qos-ch/slf4j/commit/f420e0255ff44bf30a07c6787a86a02b6355… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2014-02-22 (Sat, 22 Feb 2014) Changed paths: M slf4j-site/src/site/pages/news.html Log Message: ----------- mention Otavio Garcia

1 0