January 2017 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 19 Jan '17

19 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Joern Huxhorn commented on SLF4J-124: ------------------------------------- The problem is that you would still need to implement all of these methods for each and every enum value: {code} boolean isEnabled(Logger logger); void log(Logger logger, String msg); void log(Logger logger, String format, Object arg); void log(Logger logger, String format, Object arg1, Object arg2); void log(Logger logger, String format, Object... arguments); void log(Logger logger, String msg, Throwable t); boolean isEnabled(Logger logger, Marker marker); void log(Logger logger, Marker marker, String msg); void log(Logger logger, Marker marker, String format, Object arg); void log(Logger logger, Marker marker, String format, Object arg1, Object arg2); void log(Logger logger, Marker marker, String format, Object... argArray); void log(Logger logger, Marker marker, String msg, Throwable t); {code} I don't think that this would be a good idea. But that's just me. I'm not the owner of the project. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 19 Jan '17

19 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Anders Kreinøe commented on SLF4J-124: -------------------------------------- Now where slf4j actually has an Level enum, what about adding a log(Logger logger, String msg) method to the enum, instead of a generic log(Level level, String msg) method to Logger. It could look something like this: {code:java} public enum Level { ERROR(ERROR_INT, "ERROR") { @Override public void log(Logger logger, String msg) { logger.error(msg); } }, WARN(WARN_INT, "WARN") { @Override public void log(Logger logger, String msg) { logger.warn(msg); } }, INFO(INFO_INT, "INFO") { @Override public void log(Logger logger, String msg) { logger.info(msg); } }, DEBUG(DEBUG_INT, "DEBUG") { @Override public void log(Logger logger, String msg) { logger.debug(msg); } }, TRACE(TRACE_INT, "TRACE") { @Override public void log(Logger logger, String msg) { logger.trace(msg); } }; private int levelInt; private String levelStr; Level(int i, String s) { levelInt = i; levelStr = s; } public int toInt() { return levelInt; } /** * Returns the string representation of this Level. */ public String toString() { return levelStr; } public abstract void log(Logger logger, String msg); } {code} Then you can define a method taking a Level instance, and just call log on that. No need to know what level it actually is: {code:java} public static void doSomethind(Level logAtLevel) { // perform some logic logAtLevel.log(loggerToLogTo, "The caller of this method has decided " + "what level this is logged at."); } {code} This is only an example, a lot more methods would have to be difined on the level class, to support markers, and arguments for {} replacements. I see the following advantages when doing it this way: # Adding a new method to Logger interface would breack the backward compability, as it would force all implementations to implement these methods. However adding a log method to level, is fully backward compatibly. # I think this would give a cleaner implementation, without the need for matching (either in a switch or with if/else statements) on the level in the log methods. # More typesafe. There will be no switch or if statements matching on the level, to decide what method to call on the Logger instance. Thus adding an new Level, will result in a compile error, until the needed log methods has been implemented in that Level instance. # It still possibly to add generic log.(Level level ...) methods in the Logger interface if wanted (would still break backward compatibility), and the implementation for these would be pretty easy, just call the corresponding method on the supplied Level instance. It would be possibly to create an abstract class implementing Logger, that provide the implementation for these, that could be used by Logger implementations that do not need to extend an other class. I would be willing to work on this, and provide patches, but I will like to know if its something that would surely be rejected, before doing any work. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-390) FAILED_INITIALIZATION case in LoggerFactory.getILoggerFactory swallows root exception
by QOS.CH (JIRA) 16 Jan '17

16 Jan '17

Andreas Sewe created SLF4J-390: ---------------------------------- Summary: FAILED_INITIALIZATION case in LoggerFactory.getILoggerFactory swallows root exception Key: SLF4J-390 URL: http://jira.qos.ch/browse/SLF4J-390 Project: SLF4J Issue Type: Bug Affects Versions: 1.7.22 Reporter: Andreas Sewe Assignee: SLF4J developers list Priority: Minor I have a hard time triaging an {{IllegalStateException}} thrown by {{LoggerFactory.getILoggerFactory}} that has been reported by a user ([Eclipse Bug 510487|https://bugs.eclipse.org/bugs/show_bug.cgi?id=510487] as the root exception is not wrapped by the {{IllegalStateException}}: [https://github.com/qos-ch/slf4j/blob/v_1.7.22/slf4j-api/src/main/java/org/s…] AFAICT, that exception is only logged to the console ([https://github.com/qos-ch/slf4j/blob/v_1.7.22/slf4j-api/src/main/java/org/s…] This makes error reports sent by an automatic error reporting system (like the one employed for the Eclipse IDE) less useful, as the crucial information won't be included automatically. Hence, it would be great if SLF4J could hold onto the {{Throwable}} for a bit and than wrap it in the final {{IllegalStateException}}. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-389) SimpleLogger caches System.err and System.out
by QOS.CH (JIRA) 13 Jan '17

13 Jan '17

[ http://jira.qos.ch/browse/SLF4J-389?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on SLF4J-389: ---------------------------------- [~ipolevoy] Sorry, but no date has been set yet for this release. > SimpleLogger caches System.err and System.out > --------------------------------------------- > > Key: SLF4J-389 > URL: http://jira.qos.ch/browse/SLF4J-389 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.x > Reporter: Igor Polevoy > Assignee: Ceki Gulcu > Fix For: 1.7.23 > > > We usually use SimpleLogger in tests, and some other binding when running in production. > In some cases, our tests depend on log values logged through the logger during a test. > Unfortunately between version 1.7.0 and 1.7.1 this ability has been removed, since the SimpleLogger now caches the system stream in a static initialiser. > Here is the code that broke this approach: > https://github.com/qos-ch/slf4j/commit/996ccc7ca507994465c069554954ecb01890… > Basically, we would write a test: > {quote}PrintStream err = System.err; > PrintStream temp = new PrintStream(some buffer here); > System.err = temp; > // run tests > System.err = err; > // here we assert that the temp stream contains values we expect{quote} > Unfortunately SimpleLogger now caches the system stream and never releases it, meaning swapping the streams to catch the output is not possible. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

QOS.CH Jira username is your email address
by Ceki Gulcu 13 Jan '17

13 Jan '17

Dear SLF4J developers list , On the QOS.CH Jira instance issues can be browsed by anonymous users, that is without logging in. The Jira web-page for a given issue will contain the user name of the reporter as well as the user names for all those who commented on the issue. Thus, web-crawlers will be able to see user names on our Jira instance. This is acceptable as long as user names do not contain sensitive data. However, given that your user name matches your email address on the QOS.CH Jira instance, we fear that your email address may leak to anonymous web-crawlers (who can see your Jira user name). Please note that many other publicly accessible Jira installations suffer from the exact same problem. Modifying your user name so as to make it different than your email address should stop the aforementioned data leakage. Unfortunately, you cannot change your user name on your own. Only the Jira administrator can change it. In light of the above, if you decide to change your Jira user name, please let me know the user name of your choice by replying to this message. Best regards, -- Ceki Gülcü

1 0

[qos-ch/slf4j] 7df8af: SLF4J-389 - added a test
by Ceki Gulcu 11 Jan '17

11 Jan '17

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 7df8afcb22dd25fd156b4336ba4ade4f85014a4d https://github.com/qos-ch/slf4j/commit/7df8afcb22dd25fd156b4336ba4ade4f8501… Author: Igor Polevoy <igor(a)expresspigeon.com> Date: 2017-01-11 (Wed, 11 Jan 2017) Changed paths: M slf4j-simple/src/test/java/org/slf4j/impl/SimpleLoggerTest.java Log Message: ----------- SLF4J-389 - added a test Commit: 1ddc1f72d1281af6cad5956ed8736ad5114fa62f https://github.com/qos-ch/slf4j/commit/1ddc1f72d1281af6cad5956ed8736ad5114f… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-01-11 (Wed, 11 Jan 2017) Changed paths: M slf4j-simple/src/test/java/org/slf4j/impl/SimpleLoggerTest.java Log Message: ----------- Merge pull request #169 from ipolevoy/master SLF4J-389 - added a test Compare: https://github.com/qos-ch/slf4j/compare/b8b881b7395e...1ddc1f72d128

1 0

[JIRA] (SLF4J-389) SimpleLogger caches System.err and System.out
by Igor Polevoy (JIRA) 11 Jan '17

11 Jan '17

1 0

[qos-ch/slf4j] b8b881: follow java conventions for enums
by Ceki Gulcu 11 Jan '17

11 Jan '17

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: b8b881b7395ead1d2316a740b6a633b3ed16e994 https://github.com/qos-ch/slf4j/commit/b8b881b7395ead1d2316a740b6a633b3ed16… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-01-11 (Wed, 11 Jan 2017) Changed paths: M slf4j-simple/src/main/java/org/slf4j/impl/OutputChoice.java M slf4j-simple/src/main/java/org/slf4j/impl/SimpleLogger.java Log Message: ----------- follow java conventions for enums

1 0

SimpleLogger prints to the latest value of System.out
by Ceki Gülcü 11 Jan '17

11 Jan '17

Hello all, In issue SLF4J-389 [1] user Igor Polevoy observed that once initialized, SimpleLogger always used the same reference to System.out (or System.err). He feels that this can interfere in test where System.out is modified in order to capture log output. Commit 69be5f7f [2] ensures that SimpleLogger prints to the latest value of System.out. Please let me know if this may be an issue for you. Best regards, -- Ceki [1] http://jira.qos.ch/browse/SLF4J-389 [2] https://github.com/qos-ch/slf4j/commit/69be5f7f9875

1 0

[JIRA] (SLF4J-389) SimpleLogger caches System.err and System.out
by Ceki Gulcu (JIRA) 11 Jan '17

11 Jan '17

1 0