- slf4j-dev - mailman3.qos.ch

Passed: qos-ch/slf4j#203 (event - c3751df)
by Travis CI 02 Feb '16

02 Feb '16

Build Update for qos-ch/slf4j ------------------------------------- Build: #203 Status: Passed Duration: 40 seconds Commit: c3751df (event) Author: Ceki Gulcu Message: add event recording support SLF4J-353 View the changeset: https://github.com/qos-ch/slf4j/commit/c3751df9afec View the full build log and details: https://travis-ci.org/qos-ch/slf4j/builds/106571671 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

1 0

[JIRA] (SLF4J-167) Initialization (getILoggerFactory) is not thread safe
by Ceki Gulcu (JIRA) 02 Feb '16

02 Feb '16

1 0

[qos-ch/slf4j] c3751d: add event recording support SLF4J-353
by Ceki Gulcu 02 Feb '16

02 Feb '16

Branch: refs/heads/event Home: https://github.com/qos-ch/slf4j Commit: c3751df9afec9b412de6f888a97397af67063717 https://github.com/qos-ch/slf4j/commit/c3751df9afec9b412de6f888a97397af6706… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2016-02-02 (Tue, 02 Feb 2016) Changed paths: M slf4j-api/src/main/java/org/slf4j/LoggerFactory.java A slf4j-api/src/main/java/org/slf4j/event/EventConstants.java A slf4j-api/src/main/java/org/slf4j/event/EventRecodingLogger.java A slf4j-api/src/main/java/org/slf4j/event/Level.java A slf4j-api/src/main/java/org/slf4j/event/LoggingEvent.java A slf4j-api/src/main/java/org/slf4j/event/LoggingEventAware.java A slf4j-api/src/main/java/org/slf4j/event/SubstituteLoggingEvent.java M slf4j-api/src/main/java/org/slf4j/helpers/FormattingTuple.java M slf4j-api/src/main/java/org/slf4j/helpers/MessageFormatter.java M slf4j-api/src/main/java/org/slf4j/helpers/SubstituteLogger.java M slf4j-api/src/main/java/org/slf4j/helpers/SubstituteLoggerFactory.java M slf4j-api/src/main/java/org/slf4j/spi/LocationAwareLogger.java M slf4j-api/src/test/java/org/slf4j/helpers/MessageFormatterTest.java M slf4j-api/src/test/java/org/slf4j/helpers/SubstitutableLoggerTest.java M slf4j-ext/src/test/java/org/slf4j/dummyExt/PackageTest.java M slf4j-jdk14/src/main/java/org/slf4j/impl/JDK14LoggerAdapter.java M slf4j-log4j12/src/main/java/org/slf4j/impl/Log4jLoggerAdapter.java Log Message: ----------- add event recording support SLF4J-353

1 0

[JIRA] (SLF4J-353) add event recording support
by Ceki Gulcu (JIRA) 02 Feb '16

02 Feb '16

1 0

[JIRA] (SLF4J-352) Getting Root logger of Log4j with slf4j-log4j12-1.7.7 bridge
by Ceki Gulcu (JIRA) 27 Jan '16

27 Jan '16

1 0

[JIRA] (SLF4J-352) Getting Root logger of Log4j with slf4j-log4j12-1.7.7 bridge
by Vijay (JIRA) 27 Jan '16

27 Jan '16

1 0

Re: [slf4j-dev] event API in SLF4J
by Ralph Goers 25 Jan '16

25 Jan '16

Ceki, SLF4J has methods that take discrete parameters so that it can avoid constructing the LoggingEvent if it does’t need to. This kind of turns that upside down. That said, Lambdas create an object that contains the expensive logic to execute, without executing that logic until necessary. Typically the cost of creating the Lambda objects is insignificant. Log4j 2 already supports Lambdas while still only requiring Java 7 - we just use our own Supplier interface. I am not sure I see how what you are proposing here correlates at all to what using lambda expressions achieves. In your proposal the user has to construct the LoggingEvent before calling the log method, which implies that the whole thing needs to be wrapped in an if (logger.isDebugEnabled()) block. Lambdas free you from that. OTOH, it was proposed to you years ago that SLF4J accept Messages [1] - as Log4j 2 does now. I believe this yields more gains than what one would get with your proposal. I think exposing a LoggingEvent that includes the Marker and Level is a bad idea. While the Message interface allows for users to log complex objects, it does so by only solving for that problem and does not introduce fields that really have nothing to do with the message content being delivered. Although a bit off topic, I should point out that if SLF4J provided an AbstractLogger class that the impact of adding new methods to the Logger interface would pretty much be a non-issue. Most of the time the class extending AbstractLogger wouldn’t need to change. Currently the Log4j 2 API has 192 methods. If AbstractLogger is extended only 7 methods need to be implemented. Ralph [1] http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html <http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html>

1 0

test
by Ralph Goers 25 Jan '16

25 Jan '16

Testing - not seeing my emails show up. Ralph

2 1

Unable to reply
by Ralph Goers 25 Jan '16

25 Jan '16

Ceki, I have tried to post a reply to the event logging thread 4 times but am not seeing it show up, yet a test message went through just fine. Any idea what might be wrong? Ralph

2 1

event API in SLF4J
by Ceki Gulcu 25 Jan '16

25 Jan '16

Hi all, A few months ago, Nathan Green has made a proposal [1] to add Java 8 support to org.slf4j.Logger. His proposal has the remarkable property of being backward compatible. Other proposals have been made since on the same subject [2]. The org.slf4j.Logger interface already contains 55+ methods. Nathan's proposal adds yet new methods. A complete proposal would perhaps double or triple the number of methods to 100 or even 150. An alternative is to offer an event API allowing piecemeal construction of the logging event. Only when the event is fully constructed, is it offered to a Logger instance. Usage example LoggingEvent event = new LoggingEvent(); event.message("hello {}).parameter("world").marker(BLUE).level(DEBUG); EventLogger logger = someFactory.getLogger(); logger.log(event); Logback would fully support this interface but the same cannot be said of other logging frameworks. In that case there is not much use for introducing the interface in SLF4J instead of directly in logback. Your comments are welcome. -- Ceki [1] http://mailman.qos.ch/pipermail/slf4j-dev/2015-October/004229.html [2] https://github.com/qos-ch/slf4j/pull/70

2 2