- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-491) Deprecate or remove slf4j-log4j12
by QOS.CH (JIRA) 07 May '20

07 May '20

Joachim Durchholz created SLF4J-491: --------------------------------------- Summary: Deprecate or remove slf4j-log4j12 Key: SLF4J-491 URL: https://jira.qos.ch/browse/SLF4J-491 Project: SLF4J Issue Type: Task Components: Implementations Reporter: Joachim Durchholz Assignee: SLF4J developers list [http://logging.apache.org/log4j/1.2/index.html] states that log4j 1.2 has an unresolved security hole (unvalidated deserialization, remotely exploitable without authorization). _Java 9 having a different version string format broke log4j's version string parsing, introducing bugs into its MDC implementation, but that's much less important._ Options for the documentation: # Add a warning to the SLF4J manual that slf4j-log4j12 should not be used anymore. # Remove mentions of slf4j-log4j12 entirely. Options for the code: Since slf4j-log4j12 cannot be removed from Maven repositories, a new version that warns about the issue should be released: # Make it output an ERROR, stating "log4j 1.2 has an unfixed security hole; your application can be hacked by anybody with network access (CVE-2019-17571). Migrate to another logging backend as soon as possible." # As above, but make it abort startup. (That's probably too much, there could be edge cases where an organization cannot migrate and cannot downgrade back to a previous, working slkf4j-log4j12.) -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

[JIRA] (SLF4J-490) Better combination for logging and exceptions
by QOS.CH (JIRA) 06 May '20

06 May '20

Norbert Kiesel created SLF4J-490: ------------------------------------ Summary: Better combination for logging and exceptions Key: SLF4J-490 URL: https://jira.qos.ch/browse/SLF4J-490 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.7.29 Reporter: Norbert Kiesel Assignee: SLF4J developers list Hi, we have quite a few places in our code where we do: {code:java} logger.error("Param {} must be in [{}-{}]", name, low, high); throw new ValidationException("Param " + name + " must be in [" + low + "-" + high + "]"); {code} This is obviously ugly. Other options would be to use {code:java} String msg = String.format("Param %s must be in [%s-%s]", name, low, high); logger.error(msg); throw new ValidationException(msg);{code} or {code:java} String msg = MessageFormatter.format("Param {} must be in [{}-{}]", new Object[] {name, low, high}).getMessage(); logger.error(msg); throw new ValidationException(msg); {code} Both are not ideal. Can't we have a `Logger.format` method which returns a `FormattingTuple` w/o the explicit array creation and allow `Logger.error` etc. to be called with a `FormattingTuple`? Then I could write {code:java} FormattingTuple entry = logger.format("Param {} must be in [{}-{}]", name, low, high); logger.error(entry); throw new ValidationException(entry.getMessage());{code} For my own exception classes I could then even offer a constructor that takes a FormattingTuple and internally use the message and the throwable (if it is not null). Bonus: pick a nicer name than `FormattingTuple` like `LogEntry`. -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

OpenJDK 15 EA build 21 is now available
by Rory O'Donnell 01 May '20

01 May '20

Hi Ceki, OpenJDK 15 EA build 21 is now available at http://jdk.java.net/15 * * * 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>. * Features o Integrated in JDK 15 + JEP 371: <http://openjdk.java.net/jeps/371> Hidden Classes + JEP 372 <https://openjdk.java.net/jeps/372>: Remove the Nashorn JavaScript Engine + JEP 377 <https://openjdk.java.net/jeps/377>: ZGC: A Scalable Low-Latency Garbage Collector + JEP 378 <https://openjdk.java.net/jeps/378>: Text Blocks o JEPs targeted to JDK 15 + JEP 379 <https://openjdk.java.net/jeps/379>: Shenandoah: A Low-Pause-Time Garbage Collector * Changes in recent builds that maybe of interest: o build 21 + JDK-8242848 <https://bugs.openjdk.java.net/browse/JDK-8242848>: Improve performance of InflaterOutputStream.write() + JDK-8243574 <https://bugs.openjdk.java.net/browse/JDK-8243574>: java.lang.invoke.InvokerBytecodeGenerator.ClassData should be package-private # Reported by JaCoCo o build 20 + JDK-8237890 <https://bugs.openjdk.java.net/browse/JDK-8237890>: DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set [1] + JDK-8228991 <https://bugs.openjdk.java.net/browse/JDK-8228991>: Obsolete -XX:UseAdaptiveGCBoundary [1] + JDK-8242141 <https://bugs.openjdk.java.net/browse/JDK-8242141>: New System Properties to configure the TLS signature schemes [1] + JDK-8172404 <https://bugs.openjdk.java.net/browse/JDK-8172404>: Tools should warn if weak algorithms are used before restricting them + JDK-8238195 <https://bugs.openjdk.java.net/browse/JDK-8238195>: Lookup::defineClass should link the class to match the specification + JDK-8238358 <https://bugs.openjdk.java.net/browse/JDK-8238358>: Implementation of JEP 371: Hidden Classes + JDK-8241749 <https://bugs.openjdk.java.net/browse/JDK-8241749>: Remove the Nashorn JavaScript Engine + JDK-8242260 <https://bugs.openjdk.java.net/browse/JDK-8242260>: Add forRemoval=true to already deprecated ContentSigner + JDK- <https://bugs.openjdk.java.net/browse/JDK-8242008>8242008 <https://bugs.openjdk.java.net/browse/JDK-8242008>: SSLSession inconsistencies # Reported by Netty o build 19 + JDK-8239594 <https://bugs.openjdk.java.net/browse/JDK-8239594>: The java.net.HttpClient does not override the protocols specified in the SSLContext default parameters [1] + JDK-8172680 <https://bugs.openjdk.java.net/browse/JDK-8172680>: SunJCE provider now supports SHA-3 based Hmac algorithms + JDK-8237474 <https://bugs.openjdk.java.net/browse/JDK-8237474>: Default SSLEngine should create in server role + JDK-8240877 <https://bugs.openjdk.java.net/browse/JDK-8240877>: NPE at javax.swing.text.html.FormView.appendBuffer with null option values # reported by JOSM Project Loom Early-Access Builds - Build 15-loom+5-125 (2020/4/17) * These builds are intended for developers looking to "kick the tyres" and provide feedback on using the API or by sending bug reports. Warning: This build is based on an incomplete version of JDK 15 <http://openjdk.java.net/projects/jdk/15/>. * 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>. * Please send feedback via e-mail to loom-dev(a)openjdk.java.net <mailto:loom-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list <http://mail.openjdk.java.net/mailman/listinfo/loom-dev>. Rgds,Rory [1] http://jdk.java.net/15/release-notes -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (SLF4J-489) Does slf4j 1.6.3 support for Java 11? If not, any timeline or recommendation?
by QOS.CH (JIRA) 17 Apr '20

17 Apr '20

[ https://jira.qos.ch/browse/SLF4J-489?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-489. ------------------------------ Resolution: Not a bug This is support a question, not a bug. > Does slf4j 1.6.3 support for Java 11? If not, any timeline or recommendation? > ----------------------------------------------------------------------------- > > Key: SLF4J-489 > URL: https://jira.qos.ch/browse/SLF4J-489 > Project: SLF4J > Issue Type: Story > Affects Versions: 1.6.x > Environment: Hi Expert, > I would appreciate if you could share your knowledge related with me? Thanks. > Regards, > Xinmin > Reporter: Xinmin > Assignee: SLF4J developers list > Priority: Major > -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

[JIRA] (SLF4J-489) Does slf4j 1.6.3 support for Java 11? If not, any timeline or recommendation?
by QOS.CH (JIRA) 17 Apr '20

17 Apr '20

Xinmin created SLF4J-489: ---------------------------- Summary: Does slf4j 1.6.3 support for Java 11? If not, any timeline or recommendation? Key: SLF4J-489 URL: https://jira.qos.ch/browse/SLF4J-489 Project: SLF4J Issue Type: Story Affects Versions: 1.6.x Environment: Hi Expert, I would appreciate if you could share your knowledge related with me? Thanks. Regards, Xinmin Reporter: Xinmin Assignee: SLF4J developers list -- This message was sent by Atlassian Jira (v8.8.0#808000)

1 0

Contributing MDC-aware Executors to slf4j
by Robert Munteanu 17 Apr '20

17 Apr '20

Hi, When working with asynchronous programming models ( Netty, CompletableFuture, OSGi Promises ) it becomes problematic to propagate the MDC between the worker threads. I see such questions asked and solutions that work more or less posted, e.g. [1], [2], [3]. I think it would be worthwhile to provide basic utilities in the slf4j project, otherwise everyone keeps reinventing the wheel. I have a couple of classes ( Executor, ScheduledExecutorService ) that work well with my setup (Netty, OSGi Promises ) and would be willing to contribute them to slf4j. Is there interest in accepting such a contribution? Thanks, Robert [1]: https://stackoverflow.com/questions/28668560/using-org-slf4j-mdc-with-netty… [2]: https://stackoverflow.com/questions/49110745/how-to-retain-slf4j-mdc-loggin… [3]: https://medium.com/asyncparadigm/logging-in-a-multithreaded-environment-and…

2 3

OpenJDK 15 EA build 18 is now available
by Rory O'Donnell 10 Apr '20

10 Apr '20

Hi Ceki, OpenJDK 15 EA build 18 is now available at http://jdk.java.net/15 * * * 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>. * Schedule for JDK 15 o 2020/06/11 Rampdown Phase One o 2020/07/16 Rampdown Phase Two o 2020/08/06 Initial Release Candidate o 2020/08/20 Final Release Candidate o 2020/09/15 General Availability * Features o Proposed to target JDK 15 + JEP 371: <http://openjdk.java.net/jeps/371> Hidden Classes o JEPs targeted to JDK 15 + JEP 372 <https://openjdk.java.net/jeps/372>: Remove the Nashorn JavaScript Engine + JEP 377 <https://openjdk.java.net/jeps/377>: ZGC: A Scalable Low-Latency Garbage Collector + JEP 378 <https://openjdk.java.net/jeps/378>: Text Blocks + JEP 379 <https://openjdk.java.net/jeps/379>: Shenandoah: A Low-Pause-Time Garbage Collector * Changes in recent builds that maybe of interest: o build 18 + JDK-8240169 <https://bugs.openjdk.java.net/browse/JDK-8240169>: javadoc fails to link to non-modular api docs # Reported by JUnit5 + JDK-8241670 <https://bugs.openjdk.java.net/browse/JDK-8241670>: Enhance heap region size ergonomics to improve OOTB performance + JDK-8240745 <https://bugs.openjdk.java.net/browse/JDK-8240745>: Implementation: JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) + JDK-8225319 <https://bugs.openjdk.java.net/browse/JDK-8225319>: Remove rmic from the set of supported tools + JDK-8237490 <https://bugs.openjdk.java.net/browse/JDK-8237490>: Add support notarizing jpackage app-image and dmg o build 17 + JDK-8240676 <https://bugs.openjdk.java.net/browse/JDK-8240676> - Meet not symmetric failure when running lucene on jdk8 # Reported by Apache Lucene o Build 16 + JDK-8241039 <https://bugs.openjdk.java.net/browse/JDK-8241039> - Retire the deprecated SSLSession.getPeerCertificateChain() method + JDK-8219989 <https://bugs.openjdk.java.net/browse/JDK-8219989> - Retire the com.sun.net.ssl.internal.ssl.Provider name + JDK-8237859 <https://bugs.openjdk.java.net/browse/JDK-8237859> - C2: Crash when loads float above range check # Reported by Apache Lucene + JDK-8202469 <https://bugs.openjdk.java.net/browse/JDK-8202469> - (ann) Type annotations on type variable bounds that are also type variables are lost # Reported by ByteBuddy o Build 15 + JDK-8214245 <https://bugs.openjdk.java.net/browse/JDK-8214245> - Case insensitive matching doesn't work correctly for some character classes () * Quality Report for March 2020 was published here [1] o Thanks again for all the bug reports and feeback! Does your Project support JDK 14 - #AllTestsGreenOnJDK14 <https://twitter.com/hashtag/AllTestsGreenOnJDK14?src=hashtag_click> Rgds,Rory [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March… -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

SLF4J-168 Numeric Values in MDC for SLF4J 2.0
by Anastas Stoyanovsky 02 Apr '20

02 Apr '20

1 0

[JIRA] (SLF4J-488) Using slf4j-api-2.0.0-alpha1.jar not possible in OSGi
by QOS.CH (JIRA) 19 Mar '20

19 Mar '20

Joakim Erdfelt created SLF4J-488: ------------------------------------ Summary: Using slf4j-api-2.0.0-alpha1.jar not possible in OSGi Key: SLF4J-488 URL: https://jira.qos.ch/browse/SLF4J-488 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0.0-alpha1 Environment: OSGi Reporter: Joakim Erdfelt Assignee: SLF4J developers list The ServiceLoader pieces of the {{META-INF/manifest.mf}} are missing for OSGi. It seems to be missing the {{Require-Capability}} entry to define ServiceLoader usage. Require-Capability=osgi.serviceloader;filter:="osgi.serviceloader=org.slf4j.spi.SLF4JServiceProvider)",osgi.extender;filter:="(osgi.extender=osgi.serviceloader.processor)" For example, here's the one out of {{javax.websocket}} {code} Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo ader.processor)",osgi.serviceloader;filter:="(osgi.serviceloader=javax. websocket.ContainerProvider)";resolution:=optional;cardinality:=multipl e,osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))" {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release Announcement: General Availability of Java 14 / JDK 14
by Rory O'Donnell 18 Mar '20

18 Mar '20

Hi Ceki, **Release Announcement: General Availability of Java 14 / JDK 14 [1] * * * JDK 14, the reference implementation of Java 14, is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/14 * JDK 14 Release notes <https://www.oracle.com/technetwork/java/javase/14-relnote-issues-5809570.ht…> JDK 14 includes sixteen features [2]: 305: Pattern Matching for instanceof (Preview) 343: Packaging Tool (Incubator) 345: NUMA-Aware Memory Allocation for G1 349: JFR Event Streaming 352: Non-Volatile Mapped Byte Buffers 358: Helpful NullPointerExceptions 359: Records (Preview) 361: Switch Expressions (Standard) 362: Deprecate the Solaris and SPARC Ports 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector 364: ZGC on macOS 365: ZGC on Windows 366: Deprecate the ParallelScavenge + SerialOld GC Combination 367: Remove the Pack200 Tools and API 368: Text Blocks (Second Preview) 370: Foreign-Memory Access API (Incubator) Thanks to everyone who contributed to JDK 14, whether by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. OpenJDK 15 EA build 14 is now available at http://jdk.java.net/15 * * * 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>. * Significant changes since the last availability email: o Build 13 - JDK-8238555 <https://bugs.openjdk.java.net/browse/JDK-8238555>: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB o Build 10 - JDK-8237776 <https://bugs.openjdk.java.net/browse/JDK-8237776>: Shenandoah: Wrong result with Lucene test + Reported by Apache Lucene. o Build 9 - JDK-8222793 <https://bugs.openjdk.java.net/browse/JDK-8222793>: Javadoc tool ignores "-locale" param and uses default locale for all messages and texts + Reported by Apache Lucene. Project Metropolis Early-Access Builds - Build 14-metropolis+1-17 <http://jdk.java.net/metropolis/> (2020/3/5) * These builds are intended for developers looking to test and provide feedback on using /Graal,/ in form of native library /(libjvmcicompiler.so)/, instead of C2 as HotSpot high optimizing JIT compiler. * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Please send feedback via e-mail to metropolis-dev(a)openjdk.java.net <mailto:metropolis-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list <https://mail.openjdk.java.net/mailman/listinfo/metropolis-dev>. Regards, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004089.html [2] https://openjdk.java.net/projects/jdk/14 -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0