Hi Robert,
On 19.01.2025 18:39, Robert Middleton wrote:
If I'm understanding this correctly, this sounds like a bad idea.
While it does make the 2.x -> 3.x transition easier, it creates a
bigger issue for when you go from 2.x -> 2.y.
As long as `x` is higher than `y` there will be no problems: the
additional artifacts are not necessary in 2.x, they are just semantic
sugar. Users can still add the third-party dependencies like
`com.lmax:disruptor` themselves, but they could also just add
`log4j-async-logger` and let us choose the appropriate `disruptor`
version to use.
The additional artifacts are also meant to help solving security alerts.
Imagine a CVE is published against XZ that affects the decompression of
archives. The developer of Acme Cool Server:
1. Finds out that `xz` is a transitive dependency of his app.
2. Finds out that `xz` is pulled by the direct dependency
`commons-compress`.
3. Asks the Commons project if the problem in `xz` can affect
`commons-compress`.
4. The answer will probably be "if you use decompression, YES" and he
will need to dive into the code to see how Commons Compress is used.
5. He won't find anything in its own code and he will spend several
hours to find out the Commons Compress is used by `log4j-core`.
6. Asks us if the problem in `xz` can affect `log4j-core`.
7. We will answer "NO, the affected code is not reachable".
If we introduce a `log4j-compress` artifact that depends on
`commons-compress` and the application uses it, steps 3-5 can be skipped.
Piotr
