- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 30 May '19

30 May '19

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Robert P Thornton commented on SLF4J-371: ----------------------------------------- The above PR does not seem adequate to support what JUL provides. It appears to only wrap individual arguments in a supplier which I think would be rarely useful. To provide parity with the JUL logging via supplier, the `org.slf4j.Logger` interface should provide operations like the following: ```java public void error(Supplier<String> msg,); public void error(Supplier<String> msg, Throwable t); public void warn(Supplier<String> msg,); public void warn(Supplier<String> msg, Throwable t); public void info(Supplier<String> msg,); public void info(Supplier<String> msg, Throwable t); public void debug(Supplier<String> msg,); public void debug(Supplier<String> msg, Throwable t); public void trace(Supplier<String> msg,); public void trace(Supplier<String> msg, Throwable t); ``` > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-432) log4j-over-slf4j calls wrong methods when marker parameter is null
by QOS.CH (JIRA) 26 May '19

26 May '19

[ https://jira.qos.ch/browse/SLF4J-432?page=com.atlassian.jira.plugin.system.… ] Rufus Andrews commented on SLF4J-432: ------------------------------------- @ceki PTAL - with respect, the delay on addressing this is getting slightly ridiculous. Thanks. > log4j-over-slf4j calls wrong methods when marker parameter is null > ------------------------------------------------------------------ > > Key: SLF4J-432 > URL: https://jira.qos.ch/browse/SLF4J-432 > Project: SLF4J > Issue Type: Bug > Components: log4j-over-slf4j > Reporter: Rufus Andrews > Assignee: SLF4J developers list > Priority: Minor > > The org.slf4j.Logger interface has with-Marker and without-Marker versions of each logging method, > e.g. > public void trace(Marker marker, String format, Object arg); > vs > public void trace(String format, Object arg); > > However, the differentiatedLog method in log4j-over-slf4j ignores this and always calls the method *with* the Marker argument, even when there is no Marker. Logger implementations are then forced to defensively check for null Markers because of this error. > log4j-over-slf4j should instead call the correct (without-Marker) method when there is no Marker. > > Patch: https://github.com/qos-ch/slf4j/pull/190/ -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-458) More Multiple Argument Variants for Debug and Trace Statements
by QOS.CH (JIRA) 16 May '19

16 May '19

[ https://jira.qos.ch/browse/SLF4J-458?page=com.atlassian.jira.plugin.system.… ] DAVID MOLLITOR commented on SLF4J-458: -------------------------------------- Woops. Thanks. Adding more arguments will cut down on the number of arrays being created. Updating should give customers a performance boost. > More Multiple Argument Variants for Debug and Trace Statements > -------------------------------------------------------------- > > Key: SLF4J-458 > URL: https://jira.qos.ch/browse/SLF4J-458 > Project: SLF4J > Issue Type: Improvement > Reporter: DAVID MOLLITOR > Assignee: SLF4J developers list > Fix For: 2.0 > > > [https://www.slf4j.org/faq.html#logging_performance] > {quote} > A two argument variant is also available. For example, you can write: > logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry); > If three or more arguments need to be passed, you can make use of the Object... variant of the printing methods. For example, you can write: > logger.debug("Value {} was inserted between {} and {}.", newVal, below, above); > This form incurs the hidden cost of construction of an Object[] (object array) which is usually very small. The one and two argument variants do not incur this hidden cost and exist solely for this reason (efficiency). The slf4j-api would be smaller/cleaner with only the Object... variant. > {quote} > Please create a 3 and 4 argument variant for {{debug}} and {{trace}} statements. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

LocationAwareLogger#log(...) not working with slf4j-jdk14.jar
by O.K.U. 14 May '19

14 May '19

Hello everyone. I posted same message to slf4j-user mailing list 2 months ago, but I have no answer yet. I think that "LocationAwareLogger#log(...)" function in "slf4j-jdk14.jar" is not working. --------------------------------------------------------------------------------- logger.log(null, "test.Test", INFO_INT , "Hello {}", "World"); --------------------------------------------------------------------------------- prints "Hello {}", not "Hello World". in JDK14LoggerAdapter.java, "argArray" parameter is not used in the function. ------------------------------------------------------------------------------------------------------------------------------------------------ public void log(Marker marker, String callerFQCN, int level, String message, Object[] argArray, Throwable t) { Level julLevel = slf4jLevelIntToJULLevel(level); // the logger.isLoggable check avoids the unconditional // construction of location data for disabled log // statements. As of 2008-07-31, callers of this method // do not perform this check. See also // http://jira.qos.ch/browse/SLF4J-81 if (logger.isLoggable(julLevel)) { log(callerFQCN, julLevel, message, t); } } ------------------------------------------------------------------------------------------------------------------------------------------------ Is this a bug? -- I'm Sorry , and thanks for reading my poor English.

1 0

[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