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

[JIRA] (SLF4J-430) Remove org.slf4j.ext.EventData dut to security issue
by QOS.CH (JIRA) 21 Feb '18

21 Feb '18

Ceki Gülcü created SLF4J-430: -------------------------------- Summary: Remove org.slf4j.ext.EventData dut to security issue Key: SLF4J-430 URL: https://jira.qos.ch/browse/SLF4J-430 Project: SLF4J Issue Type: Bug Reporter: Ceki Gülcü Assignee: Ceki Gülcü Priority: Critical -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 10: First Release Candidate - JDK 10 b43
by Rory O'Donnell 13 Feb '18

13 Feb '18

Hi Ceki, *JDK 10 build 43 is our first JDK 10 Release Candidate [1]* * JDK 10 Early Access build 43 is available at : - jdk.java.net/10/ Notable changes since previous email.** *build 43 * * JDK-8194764 <https://bugs.openjdk.java.net/browse/JDK-8194764> - javac incorrectly flags deprecated for removal imports * JDK-8196678 <https://bugs.openjdk.java.net/browse/JDK-8196678> - avoid printing uninitialized buffer in os::print_memory_info on AIX * JDK-8195837 <https://bugs.openjdk.java.net/browse/JDK-8195837> - (tz) Upgrade time-zone data to tzdata2018c ** *Bug fixes reported by Open Source Projects :* * JDK-8196296 <https://bugs.openjdk.java.net/browse/JDK-8196296> Lucene test crashes C2 compilation *Security Manager Survey * If you have written or maintain code that uses the SecurityManager or related APIs such as the AccessController, then we would appreciate if you would complete this survey: https://www.surveymonkey.com/r/RSGMF3K More info on the survey [2] Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (SLF4J-384) Implement slf4j to log4j2 bridge/adapter/impl
by QOS.CH (JIRA) 11 Feb '18

11 Feb '18

[ https://jira.qos.ch/browse/SLF4J-384?page=com.atlassian.jira.plugin.system.… ] Jose Adolph commented on SLF4J-384: ----------------------------------- The current documentation makes a very good explanation of the log4j 1.2 case which is past its end of life (since 08/2015.) Since there is no mention of the existence of log4j2 (not sure why!) I also assumed the 1.2 artifact should work and lost a some hours figuring out there is another component which resides in log4j2. Maybe a note in the FAQ is in order. > Implement slf4j to log4j2 bridge/adapter/impl > --------------------------------------------- > > Key: SLF4J-384 > URL: https://jira.qos.ch/browse/SLF4J-384 > Project: SLF4J > Issue Type: New Feature > Reporter: John Tal > Assignee: SLF4J developers list > Priority: Minor > > Sorry if this is a dumb question. But I cannot find how slf4j would integrate on top of log4j2. > I have tried using slf4j 1.7.21 with log4j 2.7 and keep running into this: Failed to instantiate SLF4J LoggerFactory Reported exception: java.lang.NoClassDefFoundError: org/apache/log4j/Level at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) > From what I can see, LoggerFactory is bound to log4j pre 2.0 as there is no .logging. in the package names: package org.slf4j.impl; import org.apache.log4j.Level; import org.slf4j.ILoggerFactory; import org.slf4j.LoggerFactory; import org.slf4j.helpers.Util; import org.slf4j.spi.LoggerFactoryBinder; /** * The binding of {@link LoggerFactory} class with an actual instance of * {@link ILoggerFactory} is performed using information returned by this class. * * @author Ceki Gülcü */ public class StaticLoggerBinder implements LoggerFactoryBinder { > If I want log4j2, and don't want to be locked into API, I can't use slf4j. I have to go back to commons-logging (JCL). Seems like a waste because JCL and it's class loader / config confusion is what led to creation of slf4j. I'd rather keep on using slf4j and plug into whatever is the fastest logging framework at the time. From all the stats I see today, that is log4j2. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Pappy STĂNESCU commented on SLF4J-429: -------------------------------------- Your statement that using OFF for Logger.log is a misuse of JUL is rather eccentric, JUL would throw by itself an ILA if the argument is not allowed. Again, the use case is when the level is configured at runtime and when OFF is used to disable logging. The fact that SLF4J decides to log a record which is otherwise *not logged* in the absence of SLF4J is definitely wrong. But it's your call in the end, and I already spent too much time on this issue. > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü reopened SLF4J-429: ------------------------------ > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü resolved SLF4J-429. ------------------------------ Resolution: Not a bug > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-429: ---------------------------------- Yes, I see the problem. My assertion that logging at Level.OFF would not any trigger action is wrong. The converse is true. Logging at Level.OFF will always trigger logging (unless the logger's level was set to true). Logging at Level.OFF is a misuse of the jul logging system. In any case, SLF4JBridgeHandlerTest current behavior is quite reasonable. Changing resolution to NOT_A_BUG. > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Pappy STĂNESCU commented on SLF4J-429: -------------------------------------- Well, your own test proves the opposite, after executing the statement at line 93 in {{SLF4JBridgeHandlerTest}}, {{listAppender.list}} is of size 7... See my previous comment... > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-429: ---------------------------------- One can indeed invoke a logger with Level.OFF. However, that invocation would not trigger any further action. In particular, *no *LogRecord with level OFF would ever reach SLF4JBridgeHandler. See also source code for java.util.Logger.log() method. > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-429) jul-to-slf4j still logs OFF level
by QOS.CH (JIRA) 04 Feb '18

04 Feb '18

[ https://jira.qos.ch/browse/SLF4J-429?page=com.atlassian.jira.plugin.system.… ] Pappy STĂNESCU commented on SLF4J-429: -------------------------------------- It *is* possible to log at *any* level by calling {{java.util.logging.Logger.log}}, which is what actually jersey or any other application that wants to configure the level at runtime does. See your test {{SLF4JBridgeHandlerTest.testLevels}} failing here [https://github.com/pa314159/slf4j/tree/SLF4J-429/failure] > jul-to-slf4j still logs OFF level > --------------------------------- > > Key: SLF4J-429 > URL: https://jira.qos.ch/browse/SLF4J-429 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.7.25 > Reporter: Pappy STĂNESCU > Assignee: Ceki Gülcü > Labels: logging > > SLF4JBridgeHandler maps java.util.logging.Level.OFF to LocationAwareLogger.ERROR_INT. > This causes logging that has been turned off to still be logged at the ERROR level. > See this bug at work at https://github.com/jersey/jersey/issues/3527 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0