May 2019 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-461) Unit testing support
by QOS.CH (JIRA) 13 May '19

13 May '19

[ https://jira.qos.ch/browse/SLF4J-461?page=com.atlassian.jira.plugin.system.… ] Aaron Digulla commented on SLF4J-461: ------------------------------------- I created a fork with a sample implementation: [https://github.com/digulla/slf4j/commit/ecf2fb7943888879ce26b2842268d943ff4…] Things that I don't like about it: * You have to create one helper per supported log implementation (logback, log4j, ...). * I have to use reflection to get "aai" from logback Logger (in `RedirectLogbackLogger`). A much better API would be an "override logger" API in LoggerFactory but I didn't want to change such a central place for now. Also, the LoggerFactory would have to return wrappers in this case. Security could be an issue, too, since that would allow malicious code to "steal" loggers at runtime to prevent logging of vital information or to fish for sensitive data. > Unit testing support > -------------------- > > Key: SLF4J-461 > URL: https://jira.qos.ch/browse/SLF4J-461 > Project: SLF4J > Issue Type: New Feature > Components: Unspecified > Affects Versions: 1.7.25, 1.8.0-beta4 > Reporter: Aaron Digulla > Assignee: SLF4J developers list > Labels: test > > I would like to submit some code to help write unit tests that verify log behavior. Examples: > * Make sure that some code correctly logs errors and warnings > * The log messages contain the correct information (instead of, say, "[byte"). > * Files are logged with absolute path > * Remove (expected) stack traces from test output > My code contains a class RedirectLogger which takes lists of classes or logger names and adds appenders to those which collect log events in a list. > At the end of the test, you can call a dump() method (optionally with a filter) to get everything that was logged. > Example code before Java 8: > {code:java} > RedirectLogger rl = new RedirectLogger(Tool.class, Util.class); > try { > rl.install(); > tool.foo(); > } finally { > rl.deinstall(); > } > assertEquals("Expected log lines", rl.dump(Level.WARN)); > {code} > Example > Java 8 with method that returns value: > {code:java} > RedirectLogger rl = new RedirectLogger(Tool.class, Util.class); > Type result = rl.with(() -> { > return tool.bar(); > }); > assertEquals(..., result); > assertEquals("Expected log lines", rl.dump(Level.WARN));{code} > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-461) JUnit Support
by QOS.CH (JIRA) 13 May '19

13 May '19

Aaron Digulla created SLF4J-461: ----------------------------------- Summary: JUnit Support Key: SLF4J-461 URL: https://jira.qos.ch/browse/SLF4J-461 Project: SLF4J Issue Type: New Feature Components: Unspecified Affects Versions: 1.8.0-beta4, 1.7.25 Reporter: Aaron Digulla Assignee: SLF4J developers list I would like to submit some code to help write unit tests that verify log behavior. Examples: * Make sure that some code correctly logs errors and warnings * The log messages contain the correct information (instead of, say, "[byte"). * Files are logged with absolute path * Remove (expected) stack traces from test output My code contains a class RedirectLogger which takes lists of classes or logger names and adds appenders to those which collect log events in a list. At the end of the test, you can call a dump() method (optionally with a filter) to get everything that was logged. Example code before Java 8: {code:java} RedirectLogger rl = new RedirectLogger(Tool.class, Util.class); try { rl.install(); tool.foo(); } finally { rl.deinstall(); } assertEquals("Expected log lines", rl.dump(Level.WARN)); {code} Example > Java 8 with method that returns value: {code:java} RedirectLogger rl = new RedirectLogger(Tool.class, Util.class); Type result = rl.with(() -> { return tool.bar(); }); assertEquals(..., result); assertEquals("Expected log lines", rl.dump(Level.WARN));{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-201) Illegal Access to SINGLETON field
by QOS.CH (JIRA) 13 May '19

13 May '19

[ https://jira.qos.ch/browse/SLF4J-201?page=com.atlassian.jira.plugin.system.… ] Aaron Digulla commented on SLF4J-201: ------------------------------------- Does slf4j still support Java 1.4? If not, this issue can be closed. > Illegal Access to SINGLETON field > --------------------------------- > > Key: SLF4J-201 > URL: https://jira.qos.ch/browse/SLF4J-201 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Affects Versions: 1.6.x > Environment: Operating System: Windows XP > Platform: PC > Reporter: David Sills > Assignee: SLF4J developers list > > While running a JUnit test using SLF4J 1.6.1 under Java 1.4.2, I was unable to proceed because the lines 49-53 of the StaticLoggerBinder in the log4j-over-slf4j JAR file (well, the source for that class) read: > /** > * The unique instance of this class. > * > */ > private static final StaticLoggerBinder SINGLETON = new StaticLoggerBinder(); > The private variable was somehow involved in what the LoggerFactory was doing. Following a suggestion on the web, I replaced this line with: > /** > * The unique instance of this class. > * > */ > public static final StaticLoggerBinder SINGLETON = new StaticLoggerBinder(); > and everything works great. > It may be that there's a reason to keep the SINGLETON private, but one cannot use the logger in that case, as the JVM at runtime throws an IllegalAccessException. However, it seems (though I can find no specific reason why this might be the case) that the LoggerFactory must itself be recompiled in conjunction with this change in order to work. > It may be that SLF4J 1.6.1 shouldn't run under 1.4.2 (though I see nothing that forbids it), but if it should, this one-line change would make, I would think, a significant difference. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 13 - Early Access build 20 is available
by Rory O'Donnell 10 May '19

10 May '19

Hi Ceki, *OpenJDK builds *- JDK 13 - Early Access build 20 is available at http://jdk.java.net/13/ * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B19%22%3A%3…> * Release notes [1] *Significant changes since the last availability email* * build 20 o Removal of T-Systems Deutsche Telekom Root CA 2 certificate (JDK-8222137) o Add new FileSystems.newFileSystem methods (JDK-8218875) o Enhance auto vectorization for x86 (JDK-8222074) o Remove CollectorPolicy and its subclasses (JDK-8198505) o Drop support for pre JDK 1.4 SocketImpl implementations (JDK-8216978) * build 19 o add support for generating method handles from a variable symbol (JDK-8222744) o mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated (JDK-8222934) * build 18 o Improve String::equals warmup characteristics (JDK-8215017) o [Containers] Improve systemd slice memory limit support (JDK-8217338) Bug fixes for issues reported by Open Source Projects * build 20 o assert(Compile::current()->live_nodes() < Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit (JDK-8219520) o C2: MemNode::can_see_stored_value() ignores casts which carry control dependency (JDK-8219902) o New fix of the deadlock in sun.security.ssl.SSLSocketImpl (JDK-8219991) JEP updates since last email * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350> istargeted for JDK 13. * JEP 351: ZGC: Uncommit Unused Memory <http://openjdk.java.net/jeps/351> istargeted for JDK 13 * JEP 353: Reimplement the Legacy Socket API <http://openjdk.java.net/jeps/353> moved to Candidate * JEP 354: Switch Expressions <http://openjdk.java.net/jeps/354> moved to Candidate. OpenJDK Committers’ Workshop, 1–2 August 2019 [2] Rgds,Rory [1] http://jdk.java.net/13/release-notes [2] https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (SLF4J-460) EventRecodingLogger debug logs as TRACE
by QOS.CH (JIRA) 08 May '19

08 May '19

[ https://jira.qos.ch/browse/SLF4J-460?page=com.atlassian.jira.plugin.system.… ] Brian Harrington commented on SLF4J-460: ---------------------------------------- See SLF4J-411, it was fixed in 1.8.x, but not sure when that version will get released. There are some beta releases. > EventRecodingLogger debug logs as TRACE > --------------------------------------- > > Key: SLF4J-460 > URL: https://jira.qos.ch/browse/SLF4J-460 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.26 > Reporter: Kevin Goveia > Assignee: SLF4J developers list > Priority: Minor > > In EventRecodingLogger, the decompiled code looks like this: > > public void debug(String msg) \{ > this.recordEvent(Level.TRACE, msg, (Object[])null, (Throwable)null); > } > I recognize this might be an issue with the decompilier i'm using, but it seems unlikely. I might also be misunderstanding the code. But from what I can tell, I think it should be Level.DEBUG -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-460) EventRecodingLogger debug logs as TRACE
by QOS.CH (JIRA) 08 May '19

08 May '19

Kevin Goveia created SLF4J-460: ---------------------------------- Summary: EventRecodingLogger debug logs as TRACE Key: SLF4J-460 URL: https://jira.qos.ch/browse/SLF4J-460 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.7.26 Reporter: Kevin Goveia Assignee: SLF4J developers list Priority: Minor In EventRecodingLogger, the decompiled code looks like this: public void debug(String msg) \{ this.recordEvent(Level.TRACE, msg, (Object[])null, (Throwable)null); } I recognize this might be an issue with the decompilier i'm using, but it seems unlikely. I might also be misunderstanding the code. But from what I can tell, I think it should be Level.DEBUG -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

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

08 May '19

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-124: ---------------------------------- Obviously, SLF4J made a distinction between levels in {{org.slf4j.Logger}} about levels via printing methods such as {{Logger.debug}} {{Logger.info}} etc. However, until relatively recently, SLF4J did not have {{Level}} defined a distinct class/enum. This will change in 2.0 which introduces the notion of a piecemeally constructed {{LoggingEvent}}. As such, it makes sense to support logging at dynamic level. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > 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 > Fix For: 2.0 > > 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 (v7.3.1#73012)

1 0

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

08 May '19

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-124: ----------------------------------- I am not following. The translation you are talking about would never happen in SLF4J. SLF4J can't know anything about the logging implementation such as how to translate levels. It would happen in the binding between SLF4J and the implementation. In Log4j 2's case, I would simply modify log4j-slf4j-impl's Log4jLogger to map SLF4J log Levels to the Levels that the Log4j API uses, which is exactly what Log4j does for JUL. It really is not a big deal. I guess it might impact Logback the most since it uses SLF4J directly as its API, but I would expect SLF4J would simply inherit Logback's Level definitions. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > 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 (v7.3.1#73012)

1 0

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

08 May '19

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-124: ----------------------------------------- The big deal is that SLF4J would have to make sure that it is properly translating the levels to that backend's idea of log levels. This isn't always trivial. Also, people will expect numeric log levels to be passed through unchanged. (Oracle's JDBC is truly bizarre here: it does not differentiate between DEBUG and TRACE, it simply uses one or two dozen numeric log levels across the entire DEBUG and TRACE range defined by java.util.logging. Mapping this to non-numeric libraries like logback will not be possible, to Logback may get pressured into having a numeric log level anyway.) Re whether numeric log levels are an ugly hack: Yes, but it's the least common denominator between all logging backends, and DEBUG vs. TRACE isn't granular enough for Oracle's log levels, and with JDBC, does even make sense because the more verbose log levels can generate huge amounts of trace, so if SLF4J could support the difference between 50000 and 40000 it would be helpful for ojdbc user. (I know this is just supporting and perpetuating bad architectur. But Oracle isn't going to improve this, ever, that company is driven purely be paying customer requests and doesn't care about architecture unless it hurts themselves.) > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > 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 (v7.3.1#73012)

1 0

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

08 May '19

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-124: ----------------------------------- I am not sure what the big deal is here with implementing this. The Log4j 2 API has supported this since 2013. So we would have no trouble adding support for the new methods required for this, unless they do something truly bizarre. I suppose another way to solve this is for user's to use the Log4j 2 API and then use log4j-to-slf4j to route back to SLF4J. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > 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 (v7.3.1#73012)

1 0