December 2013 - 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 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 281] New: JCLLoggerAdapter has log.isDebugEnabled() in trace method
by bugzilla-daemon＠qos.ch 05 Feb '14

05 Feb '14

http://bugzilla.slf4j.org/show_bug.cgi?id=281 Summary: JCLLoggerAdapter has log.isDebugEnabled() in trace method Product: SLF4J Version: 1.6.x Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: Unspecified AssignedTo: slf4j-dev(a)qos.ch ReportedBy: vvolkova(a)softserveinc.com JCLLoggerAdapter contains: public void trace(String format, Object arg1, Object arg2) { if (log.isDebugEnabled()) { FormattingTuple ft = MessageFormatter.format(format, arg1, arg2); log.trace(ft.getMessage(), ft.getThrowable()); } } log.isDebugEnabled() is used instead of log.isTraceEnabled() Issue is present in the slf4j-jcl-1.7.2 for all trace methods. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 197] New: XLogger enhancements
by bugzilla-daemon＠pixie.qos.ch 05 Feb '14

05 Feb '14

http://bugzilla.slf4j.org/show_bug.cgi?id=197 Summary: XLogger enhancements Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: enhancement Priority: P1 Component: slf4j-ext AssignedTo: slf4j-dev(a)qos.ch ReportedBy: kalgon(a)hotmail.com Hi, I would like to propose to improve some methods in XLogger: <T> T exit(T result); <T extends Throwable> T throwing(T throwable); <T extends Throwable> T throwing(Level level, T throwable); so I could use them as follows: public void myMethod(String myParam, Object myOtherParam) { this.xlogger.entry(myParam, myOtherParam); if (conditionNotMet) { throw this.xlogger.throwing(new ConditionNotMetException("wrong")); } return this.xlogger.exit(myParam.concat(myOtherParam)); } Well maybe it's too much too ask after all the debates about varargs support over the years =) Xavier. -- 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 307] New: Support for JCL 1.1.3
by bugzilla-daemon＠qos.ch 15 Jan '14

15 Jan '14

http://bugzilla.slf4j.org/show_bug.cgi?id=307 Priority: P5 Bug ID: 307 Assignee: slf4j-dev(a)qos.ch Summary: Support for JCL 1.1.3 Severity: enhancement Classification: Unclassified OS: All Reporter: wolle5050(a)gmx.de Hardware: PC Status: NEW Version: 1.7.x Component: jcl-over-slf4j Product: SLF4J Add support of the Apache Commons Logging version 1.1.3. -- You are receiving this mail because: You are the assignee for the bug.

1 3

Travis automatic build TODO
by Matthew Bishop 19 Dec '13

19 Dec '13

I have set up a Travis auto-build on my SLF4J fork and configured the necessary file. It works pretty well. Have a look at the 'build badge' in the README here: https://github.com/mattbishop/slf4j/tree/travis-ci Click on that badge to go to the build result page. A new build triggers whenever a commit is made in the associated repository. The build will trigger on any change on any branch (though not on Forks). In order for Travis to be hooked up to SLF4J need someone with 'admin' privileges needs to turn Travis on for qos-ch/slf4j. Please follow Steps 1 to 2 at the site below: http://about.travis-ci.org/docs/user/getting-started/ Following these two steps takes all of 60 seconds. I have the rest of the work done, but no point pushing the change until Travis is hooked into the slf4j change event. Once the two steps are complete, please post an acknowledgement here and I can pull in the .travis.yml and README.md file into slf4j. Happy Holidays, Matt Bishop

1 0

Travis builds for github?
by Matthew Bishop 16 Dec '13

16 Dec '13

I'd like to bring up using Travis to automatically build and run slf4j unit tests on GitHub. It is nice to see that a branch builds and passes unit tests correctly. This is a free service. Have a look: http://about.travis-ci.org/docs/user/getting-started/

2 1

[qos-ch/slf4j] 212e28: Optimize logger name truncation
by Andrey Korzhevskiy 15 Dec '13

15 Dec '13

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 212e28923f352dccd04eb5d63e09046c8f0d6cba https://github.com/qos-ch/slf4j/commit/212e28923f352dccd04eb5d63e09046c8f0d… Author: Andrey Korzhevskiy <a.korzhevskiy(a)gmail.com> Date: 2013-12-15 (Sun, 15 Dec 2013) Changed paths: M slf4j-android/src/main/java/org/slf4j/impl/AndroidLoggerFactory.java Log Message: ----------- Optimize logger name truncation

1 0