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

Investigate possible use of Java System Logger over Commons Logging API #27810

Closed
mdeinum opened this issue Dec 14, 2021 · 6 comments
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement

Comments

@mdeinum
Copy link
Contributor

mdeinum commented Dec 14, 2021

In #19081 (about 5 years ago) a discussion and decision was made on how to approach logging for Spring Framework 5.0.

As the baseline of Spring Framework 6 has been lifted to Java 17 it might be worthwhile to investigate the custom log setup and use the default logging API (System.getLogger) provided by the JDK. Or at least have an explicit decision on the usage of that API for future reference.

I know that SLF4J (and thus Logback) and Log4j2 have integration for it.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Dec 14, 2021
@vpavic
Copy link
Contributor

vpavic commented Dec 20, 2021

I was under impression that the System.Logger was intended for JDK's own internal usage. The JEP 264 has the following among its non-goals:

It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage.

@ciscoo
Copy link

ciscoo commented Dec 20, 2021

The summary also has this bit:

A library or application can provide an implementation of this service in order to route platform log messages to the logging framework of its choice

As far as I know, Spring projects themselves do not require advance logging capabilities, so the bare minimum logging capabilities that is for the JDK's own needs could largely satisfy Spring's uses.

In addition, dropping spring-jcl in favor of System.getLogger may alleviate some issues with spring-jcl as noted in a Reddit thread:

It still adds more bloat to each JAR you make though, even if it is tiny.

Relies on classpath ordering.

Hijacks the package/module of a different project, this more or less guarantees it will never work with a module system be it JPMS or OSGi

Regardless, I think a discussion on logging for the next generation of Spring is warranted since the new baseline will be Java 17.

@mdeinum
Copy link
Contributor Author

mdeinum commented Dec 22, 2021

Regardless, I think a discussion on logging for the next generation of Spring is warranted since the new baseline will be Java 17.

Which is the main reason for me to open this issue. I can live with either decision To System.Logger or not to System.Logger. If there is a decision from the Spring team we can use this ticket as reference.

I was under impression that the System.Logger was intended for JDK's own internal usage. The JEP 264 has the following among its non-goals:

It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage.

Although I tentatively agree, the API provided by the System.Logger is more or less the same as with Commons Logging and provides methods for lazy log message creation, which could lead to simpler code instead of guarding it with logging checks.

@sbrannen sbrannen added this to the Triage Queue milestone Dec 22, 2021
@jhoeller jhoeller self-assigned this Jan 4, 2022
@bclozel bclozel removed this from the Triage Queue milestone Jan 4, 2022
@jhoeller jhoeller added the in: core Issues in core modules (aop, beans, core, context, expression) label Jan 4, 2022
@sbrannen sbrannen changed the title Investigate possible use of Java System Logger over Commons Logging. Investigate possible use of Java System Logger over Commons Logging API Jan 4, 2022
@vpavic
Copy link
Contributor

vpavic commented Jun 28, 2023

Any hints maybe whether the team will consider this in not too distant future? Thanks.

@ciscoo
Copy link

ciscoo commented Oct 17, 2023

Was looking at issues on Boot and remembered this one.

Wondering if those issues could have been avoided entirely if spring-jcl was replaced/superseded.

@jhoeller jhoeller added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Dec 18, 2023
@jhoeller jhoeller added this to the General Backlog milestone Dec 18, 2023
@jhoeller
Copy link
Contributor

jhoeller commented Oct 1, 2024

At this point, we intend to go with Commons Logging 1.3 as suggested by #32459 - keeping all existing logger API usage intact, just dropping the spring-jcl artifact.

@jhoeller jhoeller closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 2024
@jhoeller jhoeller removed this from the General Backlog milestone Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

7 participants