I like the idea of revisiting our jar names Volkan. Thank you for bringing this up. I _always_ have to lookup how to layer jars whenever I have to deal with a complex stack that usually involves Log4j, JUL, and Slf4j.
"bullet-proof self-explanatory names": Yes, please! I like using the "-api" postfix. That's clear. I really don't like our "log4j-core" name. We have an API and more than one implementation. The work "core" is like "common" to me. For me, I'd rather have "log4j-impl" or a different new name. The pickle, it _what_ are you implementing, the log4j-api? Well, yeah. - `log4j-api-to-slf4j` (I removed the stars to avoid RE confusion). This reminds me how good a of marketing name "Slf4j" is: "Simple", people like that, and I think it's as meaningless to be simple just like it's meaningless to have a class called FastSomething, it's all relative. "Facade" makes it even clearer (for the old school GoF savy) that not only this is an API, but that what kind of API it is. Brilliant. - `slf4j-to-log4j-api` – It is clear that this is an API-to-API bridge Nice one. Clear. Precise. As you note elsewhere in this message, the app still has to decide on an impl. - `jul-to-log4j-api`: As above. - `jul-to-log4j-core`: I understand that name as: The JUL API is implemented in terms of Log4j's own impl guts. The difference with `jul-to-log4j-api` is that we directly implement JUL? Without going though log4j-api? If that's a yes on both, do we also have both `slf4j-to-log4j-api` and `slf4j-to-log4j-core`? TY, Gary On 2024/10/10 19:36:43 Volkan Yazıcı wrote: > I am in favor of the rebranding approach and covering all bridges. That is, > I suggest adding new modules to `2.x` with bullet-proof self-explanatory > names, e.g., > > - `*log4j-api*-to-slf4j` > - `slf4j-to-*log4j-api*` – It is clear that this is an API-to-API > bridge. Nobody can cry with *"Oh! Gee! I was expecting Log4j Core to be > the implementation!"* anymore as they did in LOG4J2-3601 > <https://issues.apache.org/jira/browse/LOG4J2-3601> and #2924 > > <https://github.com/apache/logging-log4j2/pull/2924#issuecomment-2341003762> > . > - `jul-to-*log4j-api*` – It is clear that this is an API-to-API bridge, > the implementation is yet to be decided by the application. > - `jul-to-*log4j-core*` – The bridging to Log4j Core is clear; level > propagation, etc. will work out of the box. > > This approach is > > - completely *backward compatible* – old modules will be left intact > - *easy to implement* – new modules will be composed of a single > `pom.xml` file depending on old modules with sufficient inclusion/exclusion > - introduce a *uniform self-explanatory naming* convention for bridges – > one needs to be an expert to understand the difference between `log4j-jul` > and `jul-to-log4j`, this won't be necessary anymore > - aligned with our plan to *move Log4j API to its own repository* > > We just need to guide users good in the website: > > - Always use these new modules in docs > - To those looking for old modules, tell they are deprecated, and point > to successors > > > On Tue, Oct 8, 2024 at 11:58 AM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > Hi all, > > > > I have finished the PRs for all X-to-Log4j API and Log4j API-to-X > > bridges in `2.x` and `3.x`, but the PRs are still waiting for a > > review, before I merge them and release `3.0.0-beta3`. > > Sorry for the long e-mail. > > > > Summarizing the situation would be: > > > > == JUL > > > > The Log4j API-to-JUL bridge (`log4j-to-jul`) will stay in `2.x` and it > > will be referenced in `log4j-bom` version 3.x. Everything we need is > > in JUL from JDK 8. I don't see any improvements we could make using > > JDK 17. > > > > The JUL-to-Log4j API (`log4j-jul`) will be refactored in `3.x` to take > > advantage of some new JUL methods in JDK 17: > > > > * The `o.a.l.l.jul.LogManager` will be moved to a new `jul-to-log4j` > > artifact (and renamed). This is the premiere choice for JUL-to-Log4j > > API forwarding, since it replaces the JUL logging backend entirely. On > > the other hand its usage requires a lot of manual setup on the part of > > the application developer (e.g. he must set the > > `java.util.logging.manager` system property before anything in the JVM > > uses it, i.e. on the command line). Users will tolerate the class name > > change. > > > > * The `Log4jBridgeHandler`, which is used by Spring Boot, will stay in > > `log4j-jul`. This is a fallback JUL-to-Log4j API forwarding, since it > > uses the original `j.u.l.LogManager` and `j.u.l.Logger` (including > > filtering). For this reason `log4j-core` is added as a required > > dependency, so that it can propagate configured log levels to > > `j.u.l.Logger`s (this enhances performance for disabled loggers, since > > it drops the log events as fast as possible). Since there is also an > > `Slf4jBridgeHandler`, I don't expect anyone using `log4j-jul` with > > anything else than Log4j Core. > > > > [1] https://github.com/apache/logging-log4j2/pull/2935 > > > > == JPL (System.Logger) > > > > The JPL-to-Log4j API bridge requires JDK 11 or higher. So I keep it in > > version 3.x. > > > > == SLF4J > > > > The Log4j API-to-SLF4J bridge (`log4j-to-slf4j`) will stay in `2.x` > > and it will be referenced in `log4j-bom` version 3.x. Everything we > > need is in SLF4J 1.7.x. I don't see any improvements we could make > > using SLF4J 2.x. > > > > The SLF4J-to-Log4j API bridges (`log4j-slf4j-impl` and > > `log4j-slf4j2-impl`) are the problem and have caused a lot of > > discussion (see [1], [2], [3] and the last PMC meeting). > > > > There is a difference between what they are and how people use them: > > > > 1. Technically they are bridges between APIs and depend only on > > `log4j-api` and `slf4j-api`, > > 2. Many users (not Spring Boot and major actors, but smaller projects) > > use them as a single dependency they need to add to use Log4j Core. > > This usage is justified by the description of the artifacts that was > > "The Apache Log4j SLF4J API binding to Log4j 2 Core" and many sites > > like MvnRepository still use that description. This is why currently > > the bridges have a runtime `log4j-core` dependency. > > 3. Some users even use these artifacts directly in their code. For > > example they cast SLF4J Markers to our concrete implementation to add > > structured data that SLF4J is not able to provide. > > > > Now, I am categorically against allowing usage (3) in Log4j 3.x. If > > the bridges are to remain in `3.x`, they will be totally encapsulated > > in a single non-exported package (which is the recommended JPMS way > > for service providers). > > > > If we remove the bridges from 3.x (and add them to `log4j-bom` version > > 3.x), there will be a hiccup in the (2) usage: the runtime > > dependencies of `log4j-slf4j2-impl` 2.x contain `log4j-core` 2.x. If a > > user want to use Log4j Core 3.x, he needs to do it explicitly (either > > adding `log4j-core` explicitly to their POM, adding `log4j-bom` to > > dependency management or better both). > > There are two solutions to this problem: > > > > === Solution 1 > > > > We can: > > > > * drop the bridges in 3.x and add them to `log4j-bom` version 3.x > > (implemented in PR #2924[2]), > > * drop the runtime dependency on `log4j-core` in 2.x (implemented in > > PR #3038[3]), > > * document everything. > > > > The advantage of this solution is that users will be forced to add > > `log4j-core` explicitly to their POM starting with version `2.25.x`. > > > > === Solution 2 > > > > We can: > > > > * create a brand new and correctly named `slf4j-to-log4j` file and > > advertise it as SLF4J-to-Log4j API bridge. > > * in 2.x the bridge will be just an empty JAR with a dependency on > > `log4j-slf4j2-impl` and an exclusion on `log4j-core`. > > * in 3.x the bridge will be a rebranded and encapsulated > > `log4j-slf4j2-impl`. > > * the `log4j-slf4j-impl` and `log4j-slf4j2-impl` artifacts disappear > > from the 3.x branch and even from `log4j-bom`. > > > > The advantage of this solution is branding. This will break the setup > > of all users, even `spring-boot-starter-log4j2` that correctly declare > > both the SLF4J-to-Log4j API bridge and Log4j Core. On the other hand > > users can not complain about backward compatibility, since there will > > be no previous history with the `slf4j-to-log4j` artifact. > > > > Which solution would you prefer? We can also have hybrid solutions > > (solution 1 + new `slf4j-to-log4j` artifact in 3.x). > > > > Piotr > > > > [1] https://issues.apache.org/jira/browse/LOG4J2-3601 > > [2] https://github.com/apache/logging-log4j2/pull/2924 > > [3] https://github.com/apache/logging-log4j2/pull/3038 > > >
