Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Website: API Separation - "Using Log4j2 as an SLF4J Implementation" is outdated/misleading (SLF4J particularly) #1460

Closed
Chealer opened this issue May 4, 2023 · 2 comments
Labels
documentation Pull requests or issues that affect documentation slf4j Affects SLF4J integration

Comments

@Chealer
Copy link

Chealer commented May 4, 2023

Description

The Using Log4j2 as an SLF4J Implementation section of the website's API Separation page contains several outdated elements. For starters, Log4j 2.17 itself is fairly outdated, but most importantly, 1.7.32 is obsoleted by both 1.7.36 and SLF4J 2.

The worse problem is the section refers to SLF4J 1.8, which was never released:

Note that if we were using SLF4J 1.8 instead of 1.7, that requires us to use log4j-slf4j18-impl instead of log4j-slf4j-impl.

However, SLF4J does have version 2, which should not only be documented, but considered the default choice at this point.

I know that POMs (Maven) force precise version so this section is doomed to remain either frequently outdated or costly to maintain (unless versions are removed, perhaps replaced by ellipses). But a note indicating that the versions are likely outdated would help.

If I understand this section correctly, it should mention the term "provider", used by SLF4J to designate an "SLF4J implementation".

@ppkarwasz
Copy link
Contributor

@Chealer,

Thanks for the remarks. Since we use Maven Site Plugin, we can replace the static api-separation.md file with a Velocity template and use the currently used version of all components. The version of all dependencies are kept as Maven POM properties.

I agree that SLF4J 2.x should be the default one, although I wouldn't completely remove references to the 1.x series: it still has advantages, like out-of-the-box OSGI support without relying on the optional Service Loader Mediator.

IMHO terms like "adapter", "bridge", "binding" (used in SLF4J 1.x), "provider" (used in SLF4J 2.x) and "implementation" are really confusing. If I want to connect X to Y I never remember if I should look for an "X bridge", "X adapter" or "X binding". I would rather use a single expression like "X to Y adapter" that clearly states that the component forwards API X calls to backend Y.

I think we could we could start the example section with a graph representing all possible connections. This could roughly look like this with hyperlinks to the appropriate sections.

From To/From To
SLF4J 2.x log4j-slf4j2-impl Log4j 2.x Core
SLF4J 1.7.x log4j-slf4j-impl Log4j 2.x API log4j-to-slf4j SLF4J Logback
JUL log4j-jul log4j-to-jul JUL
JCL log4j-jcl
JPL log4j-jpl

If someone wants to look into it, we love PRs.

@ppkarwasz ppkarwasz added the documentation Pull requests or issues that affect documentation label May 5, 2023
@jvz jvz added the slf4j Affects SLF4J integration label Oct 15, 2023
@vy vy mentioned this issue May 8, 2024
5 tasks
@vy
Copy link
Member

vy commented May 24, 2024

Fixed by several changes implemented for #2535.

@vy vy closed this as completed May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Pull requests or issues that affect documentation slf4j Affects SLF4J integration
Projects
None yet
Development

No branches or pull requests

4 participants