From ceki at qos.ch Sun Sep 3 18:49:34 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Sun, 3 Sep 2023 18:49:34 +0200 Subject: [slf4j-user] Release of SLF4J version 2.0.9 Message-ID: <692d45c5-0f76-125c-258f-d5d0efaed346@qos.ch> Hello All, I am very pleased to announce the release of SLF4J version 2.0.9. It is now possible to specify the provider class explicitly via the "slf4j.provider" system property, yielding full control of provider loading to the end-user. Moreover, the "slf4j.provider" system property bypasses the service loader mechanism for finding providers and may shorten SLF4J initialization. A "Bill of Materials" (BOM) file was added to the SLF4J project. This was a frequently requested feature. Garret Wilson's "Improving the Maven Bill of Materials (BOM) Pattern" document was instrumental in making this happen. Please refer to the the news page for more details on this release: http://www.slf4j.org/news.html The 2.0.x series introduces a backward-compatible fluent logging API. By backward-compatible, we mean that existing logging frameworks do not have to be changed in order for the user to benefit from the fluent logging API. However, existing frameworks *must* migrate to the ServiceLoader mechanism. The resulting internal changes are detailed in the FAQ page. http://www.slf4j.org/faq.html#changesInVersion200 The 2.0.x series builds upon the the 1.8.x series which was modularized per Java Platform Module System (JPMS/Jigsaw). The 2.0.x series requires Java 8. Binary compatibility: Mixing mixing different versions of slf4j-api.jar and SLF4J provider can cause problems. For example, if you are using slf4j-api-2.0.0.jar, then you should also use slf4j-simple-2.0.0.jar, using slf4j-simple-1.5.5.jar will not work. With the exception of the fluent API (new in SLF4J 2.0.x), from the client's perspective, all versions of slf4j-api, more specifically classes in the org.slf4j package, are backward compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your provider matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used to compile a given dependency in your project. You can always use *any* version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its provider match, you should be fine. Donations and sponsorship You can also support SLF4J/logback/reload4j projects via donations and sponsorship. We thank our current supporters and sponsors for their continued contributions. Sponsorship link: https://github.com/sponsors/qos-ch Announcement mailing list: You can receive SLF4J/logback/reload4j related announcements by subscribing QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki Gülcü From e.vanoosten at grons.nl Tue Sep 5 09:08:51 2023 From: e.vanoosten at grons.nl (Erik van Oosten) Date: Tue, 5 Sep 2023 09:08:51 +0200 Subject: [slf4j-user] Release of SLF4J version 2.0.9 In-Reply-To: <692d45c5-0f76-125c-258f-d5d0efaed346@qos.ch> References: <692d45c5-0f76-125c-258f-d5d0efaed346@qos.ch> Message-ID: Hi Ceki, Since startup time is a pretty important for services running in a cloud environment, can you say more about roughly how much time could be won by this feature? Just an order of magnitude would be great. Kind regards,     Erik. Op 03-09-2023 om 18:49 schreef Ceki Gülcü via slf4j-user: > Moreover, the "slf4j.provider" system property bypasses the service > loader mechanism for finding providers and may shorten SLF4J > initialization. -- Erik van Oosten e.vanoosten at grons.nl https://day-to-day-stuff.blogspot.com From slf4j at elyograg.org Sat Sep 16 22:45:37 2023 From: slf4j at elyograg.org (Shawn Heisey) Date: Sat, 16 Sep 2023 14:45:37 -0600 Subject: [slf4j-user] how to properly activate the jul-to-slf4j bridge Message-ID: <0dca89fb-b019-43c9-8785-c411fef11193@elyograg.org> I am a committer on the Apache Solr project. The primary dependency that Solr has is Lucene, and there are a LOT more dependencies. The lucene-core jar has zero dependencies, and their intent is to keep it that way. So when they needed to implement logging, they did so using java.util.logging. Solr uses slf4j for logging. The binary package includes Jetty, and logging jars are in jetty's lib/ext folder. The ultimate logging destination in the binary package is log4j2. Before the 7.4 version of Solr, it used log4j1 as the ultimate destination -- long after log4j1 reached end of life. For a very long time Solr has had slf4j bridges in place to handle anything logged by its many dependencies. The current version of Solr uses the JCL bridge and the JUL bridge. Bridging for log4j1 is handled by log4j2. One of my fellow developers noticed that Lucene's logs were not getting logged with the Solr logs. So they added log4j's JUL bridge and a system property to use it. This created a problem when another feature was activated. See this issue: https://issues.apache.org/jira/browse/SOLR-16976 I have learned that although Solr does include the jul-to-slf4j jar, this bridge does not get activated just by having the jar in the classpath. It must be activated either in the code or in the JUL config. So I tried to add these lines to Solr's entry point, a class called SolrDispatchFilter: SLF4JBridgeHandler.removeHandlersForRootLogger(); SLF4JBridgeHandler.install(); Solr has an admin UI with a page that shows all the loggers that exist for log4j2 and allows the levels for each logger to be changed on the fly. With the log4j bridge for JUL, this page has entries for Lucene classes, but I have not been able to get those to show up with the slf4j bridge. I also tried configuring a logging.properties file with the following line in it, and setting the system property for that config to be used: handlers = org.slf4j.bridge.SLF4JBridgeHandler What do I need to do to properly activate the jul-to-slf4j bridge in Solr? How can I tell when/if it is successful? Thanks, Shawn From ceki at qos.ch Sat Sep 16 23:36:10 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Sat, 16 Sep 2023 23:36:10 +0200 Subject: [slf4j-user] how to properly activate the jul-to-slf4j bridge In-Reply-To: <0dca89fb-b019-43c9-8785-c411fef11193@elyograg.org> References: <0dca89fb-b019-43c9-8785-c411fef11193@elyograg.org> Message-ID: <5eaaa6ad-70ba-4f5f-94ca-8fb7f40c4e49@qos.ch> Hi Shawn, Comments below. On 9/16/2023 10:45 PM, Shawn Heisey via slf4j-user wrote: [cut] > I have learned that although Solr does include the jul-to-slf4j > jar, this bridge does not get activated just by having the jar in > the classpath. It must be activated either in the code or in the > JUL config. That is correct. > Solr has an admin UI with a page that shows all the loggers that > exist for log4j2 and allows the levels for each logger to be > changed on the fly. With the log4j bridge for JUL, this page has > entries for Lucene classes, but I have not been able to get those > to show up with the slf4j bridge. Please note that changing the level of the slf4j backend, log4j 2 in your case, does not affect JUL levels. You would need to propagate changes in log4j2 levels into JUL. You could do so by hand. Logback has an extension called LevelChangePropagator that does this automatically. I presume log4j2 has a similar extension. I hope this helps and let us know about your progress, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch From slf4j at elyograg.org Sun Sep 17 08:09:03 2023 From: slf4j at elyograg.org (Shawn Heisey) Date: Sun, 17 Sep 2023 00:09:03 -0600 Subject: [slf4j-user] how to properly activate the jul-to-slf4j bridge In-Reply-To: <5eaaa6ad-70ba-4f5f-94ca-8fb7f40c4e49@qos.ch> References: <0dca89fb-b019-43c9-8785-c411fef11193@elyograg.org> <5eaaa6ad-70ba-4f5f-94ca-8fb7f40c4e49@qos.ch> Message-ID: On 9/16/2023 3:36 PM, Ceki Gülcü via slf4j-user wrote: >> I have learned that although Solr does include the jul-to-slf4j >> jar, this bridge does not get activated just by having the jar in >> the classpath. It must be activated either in the code or in the >> JUL config. > > That is correct. How do I do this successfully? Is it enough to install the SLF4JBridgeHandler once at program startup? I had expected that if I had done it correctly, then the Lucene loggers would have been propagated to slf4j and then to log4j. Solr's loggers (created directly with slf4j) do appear in log4j. But the Lucene loggers aren't showing up, which means that either my expectation is wrong or I didn't activate the bridge properly. Thanks, Shawn From ceki at qos.ch Sun Sep 17 08:52:20 2023 From: ceki at qos.ch (=?UTF-8?B?Q2VraSBHw7xsY8O8?=) Date: Sun, 17 Sep 2023 08:52:20 +0200 Subject: [slf4j-user] how to properly activate the jul-to-slf4j bridge In-Reply-To: References: <0dca89fb-b019-43c9-8785-c411fef11193@elyograg.org> <5eaaa6ad-70ba-4f5f-94ca-8fb7f40c4e49@qos.ch> Message-ID: On 9/17/2023 8:09 AM, Shawn Heisey via slf4j-user wrote: > On 9/16/2023 3:36 PM, Ceki Gülcü via slf4j-user wrote: >>> I have learned that although Solr does include the jul-to-slf4j >>> jar, this bridge does not get activated just by having the jar in >>> the classpath.  It must be activated either in the code or in the >>> JUL config. >> >> That is correct. > > How do I do this successfully?  Is it enough to install the > SLF4JBridgeHandler once at program startup? Yes. > I had expected that if I had done it correctly, then the Lucene loggers > would have been propagated to slf4j and then to log4j.  Solr's loggers > (created directly with slf4j) do appear in log4j.  But the Lucene > loggers aren't showing up, which means that either my expectation is > wrong or I didn't activate the bridge properly. Installing SLF4JBridgeHandler ensures that log events are propagated from JUL to SLF4J (and then to the SLF4J logging provider). However, both JUL and SLF4J provider will perform level filtering on their own *independently*. To log an event, you need to make sure that the event passes both the JUL filters and the SLF4J provider's filters. I hope this helps, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch