- slf4j-dev - mailman3.qos.ch

[qos-ch/slf4j] 8b77c9: pre-select SLF4J as the project to search for in J...
by Ceki Gulcu 20 Mar '15

20 Mar '15

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 8b77c9f056d620af2b12ea904f888d3c28231637 https://github.com/qos-ch/slf4j/commit/8b77c9f056d620af2b12ea904f888d3c2823… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2015-03-20 (Fri, 20 Mar 2015) Changed paths: M slf4j-site/src/site/pages/bug-reporting.html Log Message: ----------- pre-select SLF4J as the project to search for in JIRA

1 0

[qos-ch/slf4j] 13fc23: slf4j now uses JIRA
by Ceki Gulcu 20 Mar '15

20 Mar '15

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 13fc2385b06bc14ce898bb36438630386b35f35f https://github.com/qos-ch/slf4j/commit/13fc2385b06bc14ce898bb36438630386b35… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2015-03-20 (Fri, 20 Mar 2015) Changed paths: M slf4j-site/src/site/pages/bug-reporting.html Log Message: ----------- slf4j now uses JIRA

1 0

Regarding new SLF4J API
by Adax Adarsh 19 Mar '15

19 Mar '15

Hi All, It would be good to have an API which take message format, arguments and throwable parameters at all levels of logging. As of now, how we are doing it is to use below mentioned way of logging(kind of hack). logger.error( messageFormat, arguments ); logger.error( messageFormat, throwable ); Which is kind of ugly but still works as a hack. The disadvantage of this kind of logging is that, it send 2 log events instead of 1 event. let me know your view on this folks. Thanks, Adarsh

2 1

[Bug 328] New: New org.apache.log4j.Category getAppender Method
by bugzilla-daemon＠qos.ch 12 Mar '15

12 Mar '15

http://bugzilla.slf4j.org/show_bug.cgi?id=328 Priority: P5 Bug ID: 328 Assignee: slf4j-dev(a)qos.ch Summary: New org.apache.log4j.Category getAppender Method Severity: enhancement Classification: Unclassified OS: Linux Reporter: gordillo.ramon(a)gmail.com Hardware: PC Status: NEW Version: unspecified Component: log4j-over-slf4j Product: SLF4J Hi. I am an architect that works with Tibco for a long time. Its businessworks product (the old 5.x) has an option to use log4j, and as new 6.x version uses slf4j and logback, we will like to start using all the potential in 5.x too. We have set up the log4j bridge, but we need the Category.getAppender(String name) method that is not currently implemented. Can you please add the following method to the log4j-over-slf4j project (org.apache.log4j.Category class)? public Appender getAppender(String name){ // return null to avoid NoSuchMethodException return null; } Many thanks. Ramón Gordillo -- You are receiving this mail because: You are the assignee for the bug.

1 1

[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 327] New: Not able to resolve method org.apache.log4jCategory.getParent
by bugzilla-daemon＠qos.ch 24 Feb '15

24 Feb '15

http://bugzilla.slf4j.org/show_bug.cgi?id=327 Priority: P5 Bug ID: 327 Assignee: slf4j-dev(a)qos.ch Summary: Not able to resolve method org.apache.log4jCategory.getParent Severity: enhancement Classification: Unclassified OS: Windows NT Reporter: him_bhar(a)hotmail.com Hardware: PC Status: NEW Version: 1.7.x Component: log4j-over-slf4j Product: SLF4J I am using a third-party API which internally uses a custom logger based on log4j. Replacing the log4j with log4j-over-slf4j doesn't help as one of the method is not present in the log4j-over-slf4j. Can't share much of the trace as data sharing policy: Caused by: java.lang.NoSuchMethodError: org.apache.log4j.Logger.getParent()Lorg/apache/log4j/Category; Verified the same in codebase of log4j-over-slf4j and this method getParent() is not present in the jar. Whereas for log4j v 1.2.17, this is present. public final Category getParent() { return this.parent; } -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 326] New: Get wrong %class content in wrapper class
by bugzilla-daemon＠qos.ch 04 Feb '15

04 Feb '15

http://bugzilla.slf4j.org/show_bug.cgi?id=326 Priority: P5 Bug ID: 326 Assignee: slf4j-dev(a)qos.ch Summary: Get wrong %class content in wrapper class Severity: enhancement Classification: Unclassified OS: Windows NT Reporter: monkeyk1987(a)gmail.com Hardware: PC Status: NEW Version: 1.7.x Component: jul-to-slf4j Product: SLF4J I define a Java Object: LogHelper, use it wrapper the logger operations, the main codes as follow: private final Logger logger; protected LogHelper(Class clazz) { this.logger = LoggerFactory.getLogger(clazz); } public void info(String msg) { if (logger.isInfoEnabled()) { logger.info(currentUser() + LOG_DELIMITER + msg); } } ... Then when i want to record log use LogHelper replace Logger, code as follow: private static final LogHelper LOG = LogHelper.create(Activity.class); In the log file can not get the current Class name(Activity class), always get LogHelper class name, the log content look like: 2014-11-28 14:39:15 xxx.infrastructure.log.LogHelper:89 - lisz|Start to generate [2014-10] Attendance-Report... the log appender configuration is: <appender name="SchedulerAppender" class="ch.qos.logback.core.FileAppender"> <file>../logs/xxx_scheduler.log</file> <append>true</append> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss} %class:%line - %msg%n</pattern> </encoder> </appender> We expect the %class is Activity class, not LogHelper class, but it is failed. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 02 Feb '15

02 Feb '15

http://bugzilla.slf4j.org/show_bug.cgi?id=133 Marco <zakmck73(a)yahoo.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zakmck73(a)yahoo.it --- Comment #16 from Marco <zakmck73(a)yahoo.it> --- Just stumbled upon this problem and agree with embedding the Lidalia extension into SLF4J. It misses something like getCurrentLogLevel() though, which would be useful as well. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 323] New: slf4j not logging VERBOSE and DEBUG messages, no matter what is Logcat's loglevel
by bugzilla-daemon＠qos.ch 02 Feb '15

02 Feb '15

http://bugzilla.slf4j.org/show_bug.cgi?id=323 Priority: P5 Bug ID: 323 Assignee: slf4j-dev(a)qos.ch Summary: slf4j not logging VERBOSE and DEBUG messages, no matter what is Logcat's loglevel Severity: normal Classification: Unclassified OS: All Reporter: zalavaari(a)gmail.com Hardware: Other Status: NEW Version: 1.7.x Component: slf4j-android Product: SLF4J It seems on android platform the isLoggable() method is always returns false for VERBOSE and DEBUG (no matter what is the actal loglevel is), so it should not be called before calling Log.d and Log.v The only slf4j version I know of where the DEBUG & VERBOSE logs are working is 1.6.1-RC1 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 325] New: BasicMDCAdapter leaks MDC information to non-child threads
by bugzilla-daemon＠qos.ch 27 Jan '15

27 Jan '15

http://bugzilla.slf4j.org/show_bug.cgi?id=325 Priority: P5 Bug ID: 325 Assignee: slf4j-dev(a)qos.ch Summary: BasicMDCAdapter leaks MDC information to non-child threads Severity: major Classification: Unclassified OS: Linux Reporter: lcwik(a)google.com Hardware: All Status: NEW Version: 1.7.x Component: jul-to-slf4j Product: SLF4J BasicMDCAdapter uses a ConcurrentHashMap which is passed by reference from the parent to the child. All child threads then share the same map reference and any modifications by one child is visible to the parent thread and also all other child threads. -- You are receiving this mail because: You are the assignee for the bug.

1 1