March 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 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 28 Mar '14

28 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=133 --- Comment #14 from Jan <janArbeit(a)wittigbox.de> --- (In reply to comment #9) > Hasn't this been implemented with org.slf4j.spi.LocationAwareLogger? > > Apart from the "log levels should be enums" in this class, I think this > feature request can be closed. Could you provide a example? At least org.slf4j.Logger needs still to support a generic log(Level level, String message, Throwable throwable) method... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 28 Mar '14

28 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=133 Jan <janArbeit(a)wittigbox.de> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |http://stackoverflow.com/qu | |estions/2621701/setting-log | |-level-of-message-at-runtim | |e-in-slf4j CC| |janArbeit(a)wittigbox.de --- Comment #13 from Jan <janArbeit(a)wittigbox.de> --- I think this shall be regarded with highest priority if the fundamental idea of slf4j is to be the last next Logging framework wrapping all others. Without this feature it will only stay one more. See votes for according question on stackoverflow: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 316] New: Exception in thread "main" java.lang.NoSuchMethodError
by bugzilla-daemon＠qos.ch 24 Mar '14

24 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=316 Priority: P5 Bug ID: 316 Assignee: slf4j-dev(a)qos.ch Summary: Exception in thread "main" java.lang.NoSuchMethodError Severity: critical Classification: Unclassified OS: other Reporter: mmoreira(a)lemontech.com.br Hardware: Other Status: NEW Version: 1.6.x Component: Core API Product: SLF4J Running... SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/Users/User/.m2/repository/org/slf4j/slf4j-log4j12/1.5.6/slf4j-log4j12-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/C:/Users/User/.m2/repository/org/glassfish/hk2/external/bean-validator/1.1.0/bean-validator-1.1.0.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: The requested version 1.5.6 by your slf4j binding is not compatible with [1.6] SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details. Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:99) at org.springframework.core.env.MutablePropertySources.addLast(MutablePropertySources.java:103) at org.springframework.core.env.StandardEnvironment.customizePropertySources(StandardEnvironment.java:78) at org.springframework.core.env.AbstractEnvironment.<init>(AbstractEnvironment.java:117) at org.springframework.core.env.StandardEnvironment.<init>(StandardEnvironment.java:54) at org.springframework.context.support.AbstractApplicationContext.createEnvironment(AbstractApplicationContext.java:427) at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:227) at org.springframework.context.support.AbstractRefreshableApplicationContext.<init>(AbstractRefreshableApplicationContext.java:90) at org.springframework.context.support.AbstractRefreshableConfigApplicationContext.<init>(AbstractRefreshableConfigApplicationContext.java:59) at org.springframework.context.support.AbstractXmlApplicationContext.<init>(AbstractXmlApplicationContext.java:61) at org.springframework.context.support.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:137) at org.springframework.context.support.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:94) at br.com.lemontech.service.util.SpringUtil.<clinit>(SpringUtil.java:13) at br.com.lemontech.service.MainClass.run(MainClass.java:65) at br.com.lemontech.service.MainClass.main(MainClass.java:40) -- You are receiving this mail because: You are the assignee for the bug.

1 1

[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 315] New: logging message and throwable into wrong log level when using debug
by bugzilla-daemon＠qos.ch 05 Mar '14

05 Mar '14

http://bugzilla.slf4j.org/show_bug.cgi?id=315 Priority: P5 Bug ID: 315 Assignee: slf4j-dev(a)qos.ch Summary: logging message and throwable into wrong log level when using debug Severity: normal Classification: Unclassified OS: Mac OS X 10.3 Reporter: kalle.karkkainen+slf4j(a)futuremark.com Hardware: All Status: NEW Version: 1.7.x Component: slf4j-android Product: SLF4J AndroidLoggingAdapter.java [262-264]: public void debug(String msg, Throwable t) { log(Log.VERBOSE, msg, t); } Should probably be: public void debug(String msg, Throwable t) { log(Log.DEBUG, msg, t); } -- You are receiving this mail because: You are the assignee for the bug.

1 0