July 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 320] New: More info at "Failed to load Class"
by bugzilla-daemon＠qos.ch 31 Jul '14

31 Jul '14

http://bugzilla.slf4j.org/show_bug.cgi?id=320 Priority: P5 Bug ID: 320 Assignee: slf4j-dev(a)qos.ch Summary: More info at "Failed to load Class" Severity: enhancement Classification: Unclassified OS: Linux Reporter: spam.trash(a)seznam.cz Hardware: PC Status: NEW Version: 1.7.x Component: Core API Product: SLF4J When SLF4J can't load some class, it just says SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details It would be very useful if it also printed out what classloader it used, and from which class it was initialized (taking this info from call stack). In modularized environments getting more used, this will become increasingly important. Thanks for considering. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 319] New: Missing version in pom files
by bugzilla-daemon＠qos.ch 07 Jul '14

07 Jul '14

http://bugzilla.slf4j.org/show_bug.cgi?id=319 Priority: P5 Bug ID: 319 Assignee: slf4j-dev(a)qos.ch Summary: Missing version in pom files Severity: blocker Classification: Unclassified OS: other Reporter: bdupraz.ext(a)deltadore.com Hardware: PC Status: NEW Version: 1.7.x Component: Implementations Product: SLF4J When using Ivy to resolve dependency in my project with this line: <dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" /> slf4j-api-1.7.5.jar and log4j-1.2.17.jar aren't resolve. I've open the ivy-1.7.5.xml file in Ivy cache, I've got this : <dependency org="org.slf4j" name="working@xxxxxxxx" rev="1.7.5" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/> <dependency org="log4j" name="log4j" rev="working@xxxxxxxx" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/> At working@xxxxxxxx, the xxxxxxxx are my machine host name. When I edit the file with dependency found on Maven central like this: <dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/> <dependency org="log4j" name="log4j" rev="1.2.17" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/> It works as soon as I trigger a new resolve with Ivy. So I looked in the pom file on Maven Central and I found that the required version attribute in dependencies are missing. Here the extract of the pom file currently on Maven Central: <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </dependency> </dependencies> and here is what it should be: <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.5</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> </dependency> </dependencies> This problem appears on every versions of slf4j-log4j12 -- You are receiving this mail because: You are the assignee for the bug.

1 4