- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 02 Jan '19

02 Jan '19

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Andrea Santi commented on SLF4J-192: ------------------------------------ I understand that SL4J general idea is about having a simple facede library. It is true that I have a file configuring the real logging framework used behind SLF4J (log4j2 in my case) and the related backend dependency (this is inevitable). However, this is the only touching point to the underlying logging framework: all the rest is managed by SLF4J. This is not bad and totally in accordance with the idea of the facade: with the effort of a little setup the extra-complexity of the underlying logging framework is hidden. It's like having a wall separating the two worlds. I really would love things to remain like that! Having a "shutdown" method in the SLF4J interface is not going to change the nature of the facade: most of the logging framework have this feature and it is trivial to implement a sort of "nop" method for logging frameworks not having this functionality. "*If I am building a code dependency on the underlying logger, why even use SLF4J?"* --> I intended this sentence that I quoted *not* as _"I have an additional dependency in my project"_ but something like _"If I have to write in my class some framework-specific code then I can just get rid of SLF4J and use directly the specific logging framework"_. The idea of using SLF4J should be that I don't rely on framework-specific code right? These are just my two cents... > Need ability to shutdown loggers and flush appenders > ---------------------------------------------------- > > Key: SLF4J-192 > URL: https://jira.qos.ch/browse/SLF4J-192 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.6.x > Environment: Operating System: All > Platform: All > Reporter: Michael Schall > Assignee: SLF4J developers list > > There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. > Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? > For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); > For logback it would call - loggerContext.stop() > Other back ends - ??? > This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. > Discussion about this is happening on the user list at - > http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-451) org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data.
by QOS.CH (JIRA) 25 Dec '18

25 Dec '18

[ https://jira.qos.ch/browse/SLF4J-451?page=com.atlassian.jira.plugin.system.… ] Igor Stepanov commented on SLF4J-451: ------------------------------------- Same is reproducible for {{1.7.25}}. It's detected by {{org.owasp:dependency-check-maven:check}} maven command. We get next output after the check: {code} slf4j-api-1.7.25.jar (org.slf4j:slf4j-api:1.7.25, cpe:/a:slf4j:slf4j:1.7.25) : CVE-2018-8088 {code} > org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SLF4J-451 > URL: https://jira.qos.ch/browse/SLF4J-451 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.8.0-beta2 > Environment: Linux > Reporter: Narayan > Assignee: SLF4J developers list > Labels: logging > > More details is available in [https://nvd.nist.gov/vuln/detail/CVE-2018-8088|https://nvd.nist.gov/vuln/de…] -- 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) 24 Dec '18

24 Dec '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Roded commented on SLF4J-371: ----------------------------- Any update on this issue? Kind of a pain that SLF4J misses what JUL has since Java 8. > 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-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 23 Dec '18

23 Dec '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-192: ----------------------------------------- You have a backend dependency anyway. At least you have a logback.xml (or whatever configuration file you use). Whatever has this file - main program, application container, whatever - is also the right place to close logging resources. No facade is perfect - you need to set it up and tear it down somewhere. The point of a facade is not to remove all traces, it is to concentrate them in a single place where it is easy to control. > Need ability to shutdown loggers and flush appenders > ---------------------------------------------------- > > Key: SLF4J-192 > URL: https://jira.qos.ch/browse/SLF4J-192 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.6.x > Environment: Operating System: All > Platform: All > Reporter: Michael Schall > Assignee: SLF4J developers list > > There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. > Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? > For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); > For logback it would call - loggerContext.stop() > Other back ends - ??? > This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. > Discussion about this is happening on the user list at - > http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 23 Dec '18

23 Dec '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Andrea Santi commented on SLF4J-192: ------------------------------------ 8 years? Really? After 8 years we are still debating about this? There are some resources that need to be cleaned when the application close. There are some appenders that need to shutdown resources gracefully when an application is closed. E.g. the logfaces appender creates background threads to send logs to an external log monitoring system and without a proper shutdown hook in SLF4J api they are destined to stay there in background and create a huge leak. Since I'm using log4j 2 as the underlying logging library today I'm forced to do the following *LogManager.shutdown();* But this is so wrong! It entirely blows up the idea of the *FACADE*. If we need to directly call a method of the *REAL* implementation of the logging library then this is not a FACADE anymore. I totally agree with Alexander and Sean. " *If I am building a code dependency on the underlying logger, why even use SLF4J?* What can be done to make things progress? Open another ticket (version 1.6 is no longer "actual")? Any feedback woudl be really appreciated. > Need ability to shutdown loggers and flush appenders > ---------------------------------------------------- > > Key: SLF4J-192 > URL: https://jira.qos.ch/browse/SLF4J-192 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.6.x > Environment: Operating System: All > Platform: All > Reporter: Michael Schall > Assignee: SLF4J developers list > > There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. > Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? > For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); > For logback it would call - loggerContext.stop() > Other back ends - ??? > This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. > Discussion about this is happening on the user list at - > http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-451) org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data.
by QOS.CH (JIRA) 19 Dec '18

19 Dec '18

Narayan created SLF4J-451: ----------------------------- Summary: org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data. Key: SLF4J-451 URL: https://jira.qos.ch/browse/SLF4J-451 Project: SLF4J Issue Type: Bug Components: slf4j-ext Affects Versions: 1.8.0-beta2 Environment: Linux Reporter: Narayan Assignee: SLF4J developers list More details is available in [https://nvd.nist.gov/vuln/detail/CVE-2018-8088|https://nvd.nist.gov/vuln/de…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-450) Allow binding to be explicitly specified
by QOS.CH (JIRA) 17 Dec '18

17 Dec '18

Chris Lee created SLF4J-450: ------------------------------- Summary: Allow binding to be explicitly specified Key: SLF4J-450 URL: https://jira.qos.ch/browse/SLF4J-450 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.8.0-beta2 Reporter: Chris Lee Assignee: SLF4J developers list Currently SLF4J (1.8+) uses ServiceLoader to find bindings; as an improvement for performance sensitive (or otherwise restricted) environments allow the binding to be explicitly specified. For example: {code:java} -Dslf4j.binding=ch.qos.logback.classic.spi.LogbackServiceProvider{code} In the event this property isn't specified then logic could fall-through to existing ServiceLoader behaviour. Examples of where this would be valuable: 1) Cloud functions sensitive to cold-start times (e.g. AWS Lambda). Avoiding scanning the classpath reduces startup time (and hence request processing time for requests incurring a cold start). This is the my use case. 2) Class-loader challenged environments where ServiceLoader may not behave as expected; specifying the precise class to load may allow for workarounds. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Status of EventData removal defect
by Michael Ahern 14 Dec '18

14 Dec '18

1 0

JDK 12 enters Rampdown Phase One
by Rory O'Donnell 14 Dec '18

14 Dec '18

Hi Ceki, *JDK 12 Early Access build **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o We’ve forked the main-line source repository, jdk/jdk, to the JDK 12 stabilization repository. Changes since the last availability email * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) <http://openjdk.java.net/jeps/189> moved to *Targeted*. * JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> moved to *Targeted*. * JEP 344: Abortable Mixed Collections for G1 <http://openjdk.java.net/jeps/344> moved to *Targeted*. * JEP 346: Promptly Return Unused Committed Memory from G1 <http://openjdk.java.net/jeps/346> to *Targeted*. * JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326> (Preview) *Proposed to drop from JDK 12* o link to proposal on jdk-dev <https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html> Bug fixes reported by Open Source Projects : o JDK-8211051 - fixed in b22 - reported by JUnit5 o JDK-8211422 - fixed in b23 - reported by Apache Batik The Java Crypto Roadmap <https://java.com/cryptoroadmap> has been updated with the following target: * With the 2019-04-16 CPU, o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7 o Distrust TLS server certificates anchored by Symantec Root CAs. Oracle Java SE 8 Release Updates [3] * Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license. Rgds, Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html [3] https://java.com/en/download/release_notice.jsp -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

jpms update...
by John Patrick 09 Dec '18

09 Dec '18

hello calling any slf4j developers/commiters... looking at jira and github i can't see any activity since March 2018 when 1.8.0-beta2 was released... 1) any update on if 1.7.26 might be release to unblock anyone downstream wanting to use slf4j in a pure Java 9+ with modules application??? i'm specifically referring to this https://github.com/qos-ch/slf4j/pull/184 2) if 1.7.26 is not going to be release, any update on then 1.8.0 will be finally released? As the 1st alpha was Apr 2017 and last beta Mar 2018. Any blocking defects, blocking dependencies or outstanding testing that needs to be done? Any assistance needed? Cheers, Downstream Consumer

1 0