July 2018 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-440) Update documentation with reference how to use Slf4j with Log4j2 (v2.x)
by QOS.CH (JIRA) 18 Jul '18

18 Jul '18

Oleksandr Gavenko created SLF4J-440: --------------------------------------- Summary: Update documentation with reference how to use Slf4j with Log4j2 (v2.x) Key: SLF4J-440 URL: https://jira.qos.ch/browse/SLF4J-440 Project: SLF4J Issue Type: New Feature Environment: It looks like Apache project took efforts to provide bridge from Log4j v2 to Slf4j. Main entry point for Slf4j bridge documentation is on page: https://www.slf4j.org/legacy.html Also pictures ant text miss Log4j2 on pages: [https://www.slf4j.org/manual.html] and [https://www.slf4j.org/faq.html] External documentation is available on: [https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/ |https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/](The Log4j 2 to SLF4J adapter is dependent on the Log4j 2 API and the SLF4J API) [https://logging.apache.org/log4j/2.0/faq.html] (You can use the log4j-to-slf4j adapter jar when your application calls the Log4j 2 API and you want to route logging calls to a SLF4J implementation) Reporter: Oleksandr Gavenko Assignee: SLF4J developers list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-439) OSGi dependency on CAL10N not optional
by QOS.CH (JIRA) 17 Jul '18

17 Jul '18

Mike Mansell created SLF4J-439: ---------------------------------- Summary: OSGi dependency on CAL10N not optional Key: SLF4J-439 URL: https://jira.qos.ch/browse/SLF4J-439 Project: SLF4J Issue Type: Bug Components: slf4j-ext Affects Versions: 1.7.25 Reporter: Mike Mansell Assignee: SLF4J developers list Priority: Minor SLF4J-369 makes the CAL10N library optional from a Maven dependency point-of-view. However, it does not make it optional from an OSGi dependency point-of-view. The MANIFEST.MF should have a corresponding optional entry added: {code:java} ch.qos.cal10n;version=0.8.1;resolution:=optional{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 22 & JDK 12 Early Access b02 are available.
by Rory O'Donnell 17 Jul '18

17 Jul '18

Hi Ceki, *JDK 11 is in Rampdown Phase one* * *The overall feature set is frozen. No further JEPs will be targeted to this release.* * *Rampdown Phase two is scheduled to start * *26th of July* **JDK 11 EA build 22 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. *** * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes *FOSS fixes in recent builds.* * JBoss Netty (b17) - JDK-8203937 (b17) * JUnit5 & other Foss Projects (b22) -JDK-8206355 **Notable changes in JDK 11 EA *build 22* * New Collection.toArray(IntFunction) Default Method (JDK-8060192 <http://bugs.openjdk.java.net/browse/JDK-8060192>) * Make some system properties effectively readonly (JDK-8066709 <http://bugs.openjdk.java.net/browse/JDK-8066709>) * Obsolete Support for Commercial Features (JDK-8202331 <http://bugs.openjdk.java.net/browse/JDK-8202331>) * JFR start failure after AppCDS archive created with JFR StartFlightRecording (JDK-8203664 <http://bugs.openjdk.java.net/browse/JDK-8203664>) * Change to policy for the default set of modules resolved when compiling or running code on the class path (JDK-8197532 <http://bugs.openjdk.java.net/browse/JDK-8197532>) *JDK 12 Early Access Build 02 is available at **http://jdk.java.net/12/* * OpenJDK builds o These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build are listed here <http://hg.openjdk.java.net/jdk/jdk/log?revcount=10000&rev=reverse%28%22jdk-…> *The Quality Report for July 2018 is published **here <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+for+J…>* * With the new six months release , we now publish the Quality report every three months. * Thanks to all the FOSS Projects for logging bugs against the JDK 11 EA Builds! Rgds,Rory [1] http://openjdk.java.net/projects/jdk/11/

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 05 Jul '18

05 Jul '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Gary Gregory commented on SLF4J-371: ------------------------------------ Understood and thank you for providing context. Don't rock that boat :) > 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-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 05 Jul '18

05 Jul '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Eric Deandrea commented on SLF4J-371: ------------------------------------- Thanks @garydgregory. The problem is we're tightly integrated with the SLF4J APIs (i.e. MDC, etc) and swapping out the entire logging facade would be a big headache through hundreds of applications within a large enterprise. > 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-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 05 Jul '18

05 Jul '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Gary Gregory commented on SLF4J-371: ------------------------------------ FYI: Log4j 2 has its own facade API (unlike version 1.) > 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-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 05 Jul '18

05 Jul '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Eric Deandrea commented on SLF4J-371: ------------------------------------- I agree I like the way Log4J2 has implemented it but I still like being able to use the SLF4J abstraction in front of my logging framework implementation. > 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-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 04 Jul '18

04 Jul '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Oleksandr Gavenko commented on SLF4J-371: ----------------------------------------- [https://github.com/kwon37xi/slf4j-lambda] [https://stackoverflow.com/questions/41255503/lambda-support-for-slf4j-api] BTW Log4j 2.4 supports lambda in logging statement, like: _logger.debug("I am logging that \{} happened.", () -> compute());_ > 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-438) IllegalAccessError in MDC when using Java 10
by QOS.CH (JIRA) 03 Jul '18

03 Jul '18

[ https://jira.qos.ch/browse/SLF4J-438?page=com.atlassian.jira.plugin.system.… ] Andreas Bergander commented on SLF4J-438: ----------------------------------------- I noticed that there are some fixes for this issue in the 1.8.0 branch but I still get this error: {noformat} java.lang.IllegalAccessException: class org.apache.log4j.MDCFriend cannot access a member of class org.apache.log4j.MDC with modifiers "static final" at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) at java.base/java.lang.reflect.Field.checkAccess(Field.java:1075) at java.base/java.lang.reflect.Field.get(Field.java:416) at org.apache.log4j.MDCFriend.fixForJava9(MDCFriend.java:15) at org.slf4j.log4j12.Log4jMDCAdapter.<clinit>(Log4jMDCAdapter.java:38) at org.slf4j.impl.StaticMDCBinder.getMDCA(StaticMDCBinder.java:60) at org.slf4j.MDC.bwCompatibleGetMDCAdapterFromBinder(MDC.java:99) at org.slf4j.MDC.<clinit>(MDC.java:108) {noformat} > IllegalAccessError in MDC when using Java 10 > -------------------------------------------- > > Key: SLF4J-438 > URL: https://jira.qos.ch/browse/SLF4J-438 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.25, 1.8.0-beta2 > Environment: Java 10 > slf4j-api-1.7.25 > slf4j-log4j12-1.7.25 > Reporter: Andreas Bergander > Assignee: SLF4J developers list > > When using MDC and log4j I get an IllegalAccessError during initialization. > {noformat} > java.lang.IllegalAccessError: tried to access field org.apache.log4j.MDC.mdc from class org.apache.log4j.MDCFriend > at org.apache.log4j.MDCFriend.fixForJava9(MDCFriend.java:11) > at org.slf4j.impl.Log4jMDCAdapter.<clinit>(Log4jMDCAdapter.java:38) > at org.slf4j.impl.StaticMDCBinder.getMDCA(StaticMDCBinder.java:59) > at org.slf4j.MDC.bwCompatibleGetMDCAdapterFromBinder(MDC.java:99) > at org.slf4j.MDC.<clinit>(MDC.java:108) > {noformat} > I guess package private fields are not accessible between different jar-files anymore in Java 10. Or am I doing something wrong? > -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 is now in Rampdown Phase one
by Rory O'Donnell 02 Jul '18

02 Jul '18

Hi Ceki, *JDK 11 is now in Rampdown Phase one*** The overall feature set is frozen. No further JEPs will be targeted to this release.We’ve forked the main-line source repository, jdk/jdk, to the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or jdk/client are now bound for JDK 12. * For more details , see Mark Reinhold's email to jdk-dev mailing list [1] * The Rampdown Phase one process [2]. *Note: -* Early-Access build archive format on Windows has changed to zip. Since our last email the following JEPs have been targeted to JDK 11 : * 181: Nest-Based Access Control * 315: Improve Aarch64 Intrinsics * 330: Launch Single-File Source-Code Programs * 331: Low-Overhead Heap Profiling * 332: Transport Layer Security (TLS) 1.3 * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) * 335: *Deprecate the Nashorn JavaScript Engine* * 336: *Deprecate the Pack200 Tools and API* Other important changes since last email: Build 19: JDK-8205043 <https://bugs.openjdk.java.net/browse/JDK-8205043> : G1 enables adaptive parallel reference processing by default Build 18: JDK-8196141 <https://bugs.openjdk.java.net/browse/JDK-8196141> : Add GoDaddy root certificates JDK-8204243 <https://bugs.openjdk.java.net/browse/JDK-8204243> : *remove Thread.destroy() and Thread.stop(Throwable)* JDK-8202088 <https://bugs.openjdk.java.net/browse/JDK-8202088> : Japanese New Era Implementation Build 17: JDK-8189949 <https://bugs.openjdk.java.net/browse/JDK-8189949> : Remove Baltimore Cybertrust Code Signing CA JDK-8191031 <https://bugs.openjdk.java.net/browse/JDK-8191031> : Remove several Symantec Root CAs JDK-8072996 <https://bugs.openjdk.java.net/browse/JDK-8072996> : Deprecate stream-based GSSContext methods Build 16: JDK-8191844 <https://bugs.openjdk.java.net/browse/JDK-8191844> : Remove SECOM root Rgds, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001509.html [2] http://openjdk.java.net/projects/jdk/11/#Schedule

1 0