Re: Bridges in 2.x and 3.x

2024-10-23 Thread Piotr P. Karwasz
Hi all,

On Tue, 22 Oct 2024 at 18:52, Piotr P. Karwasz  wrote:
> Since I would like to release `3.0.0-beta3` some time soon and we did
> not reach a larger consensus, I propose to:
>
> - Remove **all** the bridges from `3.0.0-beta3`, with the exception of
> `Log4jBridgeHandler`, which is not an API-to-API bridge, but an
> appender for JUL user by Spring Boot.
> - Create a `logging-slf4j` repo that will contain the SLF4J-to-Log4j
> and Log4j-to-SLF4J bridge,
> - Create a `logging-jul` repo that will contain the JUL-to-Log4j and
> Log4j-to-JUL bridges.
> - Add to `log4j-bom` the references to the 2.x version of the bridges.
>
> What do you think?

After discussing this with Volkan on Slack and taking into account the
comments in this thread, I would revise my proposal to:

- Remove **all** the bridges from the `main` branch. For now I would
keep the reduced version of `log4j-jul` (with just
Log4jBridgeHandler`) to make it easier to test with Spring Boot.

- Create a new `logging-slf4j` repository with modules:
  * `log4j-api-to-slf4j`: a renamed version of `log4j-to-slf4j` (from 2.x),
  * `slf4j-to-log4j-api`: a renamed version of `log4j-slf4j2-impl` (from 2.x).

- Create a new `logging-jdk` repository with modules:
  * `log4j-api-to-jul`: a renamed version of `log4j-to-jul` (from 2.x),
  * `jul-to-log4j-api`: a renamed version of the `jul-to-log4j`
artifact I recently added to 3.x,
  * `jpl-to-log4j-api`: a renamed version of the `log4j-jpl` artifact
(from 2.x).

The `logging-slf4j` repo will have the same JDK baseline as SLF4J
(currently JDK 8). The `logging-jdk` repo will have the same JDK
baseline as the last modification to either JUL or JPL (currently 9).

What do you think?

Piotr


Re: Bridges in 2.x and 3.x

2024-10-23 Thread Gary D. Gregory
Another batch of repositories? -1 and you must be joking. We really are going 
off the map here IMO :(

Releasing different jars from one repo is the same as releasing jars from one 
SSD: A repo is just a folder with subfolders you can organize as you best see 
fit. So why have 10 repos? Or how ever many we have now splintered Log4j into? 
It's not like we document it. I bet devs put all Log4j repos in the same folder 
anyway... Does STF funding work by getting paid on a per repo basis? Sigh.

At some point in the future I only hope someone will reign in this mad cow bug 
we've caught and use a mono repo for Log4j.

I'm have some work to contributing here soon but this is all noise that gets in 
the way IMO.

Gary

On 2024/10/23 08:39:52 "Piotr P. Karwasz" wrote:
> Hi all,
> 
> On Tue, 22 Oct 2024 at 18:52, Piotr P. Karwasz  
> wrote:
> > Since I would like to release `3.0.0-beta3` some time soon and we did
> > not reach a larger consensus, I propose to:
> >
> > - Remove **all** the bridges from `3.0.0-beta3`, with the exception of
> > `Log4jBridgeHandler`, which is not an API-to-API bridge, but an
> > appender for JUL user by Spring Boot.
> > - Create a `logging-slf4j` repo that will contain the SLF4J-to-Log4j
> > and Log4j-to-SLF4J bridge,
> > - Create a `logging-jul` repo that will contain the JUL-to-Log4j and
> > Log4j-to-JUL bridges.
> > - Add to `log4j-bom` the references to the 2.x version of the bridges.
> >
> > What do you think?
> 
> After discussing this with Volkan on Slack and taking into account the
> comments in this thread, I would revise my proposal to:
> 
> - Remove **all** the bridges from the `main` branch. For now I would
> keep the reduced version of `log4j-jul` (with just
> Log4jBridgeHandler`) to make it easier to test with Spring Boot.
> 
> - Create a new `logging-slf4j` repository with modules:
>   * `log4j-api-to-slf4j`: a renamed version of `log4j-to-slf4j` (from 2.x),
>   * `slf4j-to-log4j-api`: a renamed version of `log4j-slf4j2-impl` (from 2.x).
> 
> - Create a new `logging-jdk` repository with modules:
>   * `log4j-api-to-jul`: a renamed version of `log4j-to-jul` (from 2.x),
>   * `jul-to-log4j-api`: a renamed version of the `jul-to-log4j`
> artifact I recently added to 3.x,
>   * `jpl-to-log4j-api`: a renamed version of the `log4j-jpl` artifact
> (from 2.x).
> 
> The `logging-slf4j` repo will have the same JDK baseline as SLF4J
> (currently JDK 8). The `logging-jdk` repo will have the same JDK
> baseline as the last modification to either JUL or JPL (currently 9).
> 
> What do you think?
> 
> Piotr
> 


Re: Bridges in 2.x and 3.x

2024-10-23 Thread Gary D. Gregory
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
> and #2924
>
> 
>.
>- `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 
> 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
> > any

Re: Bridges in 2.x and 3.x

2024-10-23 Thread Piotr P. Karwasz
Hi Gary,

On Wed, 23 Oct 2024 at 12:51, Gary D. Gregory  wrote:
> Releasing different jars from one repo is the same as releasing jars from one 
> SSD: A repo is just a folder with subfolders you can organize as you best see 
> fit. So why have 10 repos? Or how ever many we have now splintered Log4j 
> into? It's not like we document it. I bet devs put all Log4j repos in the 
> same folder anyway...

The JUL and SLF4J components have a different lifecycle from the rest
of Log4j. Since everything that ends up in our source archive might as
well be released as a binary artifact, we have two choices:

* We can keep **identical** versions of those artifacts in both the
`2.x` and `main` branches. Since, unlike the Tomcat team, we are not
used to work on multiple branches, I doubt those modules will remain
synchronized for long.
* We can keep them in a separate repository with a different lifecycle.

It is probably worth noting that Dependabot has a lot of problems with
upgrading SLF4J, since we use two different versions in two different
modules of the same repo.

> Does STF funding work by getting paid on a per repo basis? Sigh.

Since our STF funding has brought many misunderstandings inside the
PMC, I will answer this obviously rhetorical question.
We are paid by milestones[1] that we negotiated with the STF at the
beginning of the contract. These milestones cover some very specific
aspects of the development of Log4j and initially didn't contain
**any** mention of `3.x`.
For the past 13 months Christian, Volkan and I were contributing both
some paid work (the commits strictly necessary to finish our
milestones) and the usual volunteer work (like the usual bug fixes and
answering user reports). To be clear, releasing 3.0.0 is not part of
our paid duties.

Piotr

[1] 
https://github.com/apache/logging-log4j2/issues?q=is%3Aissue+label%3ASTF-Milestones


Re: Bridges in 2.x and 3.x

2024-10-23 Thread Piotr P. Karwasz
Hi Gary,

On Wed, 23 Oct 2024 at 13:11, Gary D. Gregory  wrote:
> - `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`?

To be honest, I don't like this name either. Currently `log4j-jul` has
a JUL appender that can be used if the user cannot replace the JUL
implementation with a bridging implementation. Since the performance
of such a solution sucks (to capture all JUL log events you end up
configuring the JUL threshold to ALL), there is also a Log4j Core
configuration listener that synchronizes the thresholds used by JUL
and Log4j Core. This "solution" gives users the possibility to capture
JUL log events, but Spring Boot does not enable it, unless it is
running in standalone mode.

Piotr