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

Simplify creation of LoggingCacheErrorHandler with logged stacktrace #28670

Conversation

vpavic
Copy link
Contributor

@vpavic vpavic commented Jun 21, 2022

At present, creating LoggingCacheErrorHandler that logs stacktrace also requires supplying the logger to be used. This might be inconvenient for some users, as it requires usage of Commons Logging API.

This commit simplifies creation of such as LoggingCacheErrorHandler instance by adding a constructor that only accepts a boolean flag indicating whether to log stacktrace.


This was originally a part of:

For consideration:

The first commit could maybe be update to deprecate the existing constructor that takes org.apache.commons.logging.Log and replace it with the one that takes String representing logger name as that way Commons Logging dependency wouldn't leak out at all. But I'd leave that decision to whoever reviews this PR.

At present, creating LoggingCacheErrorHandler that logs stacktrace also requires supplying the logger to be used. This might be inconvenient for some users, as it requires usage of Commons Logging API.

This commit simplifies creation of such as LoggingCacheErrorHandler instance by adding a constructor that only accepts a boolean flag indicating whether to log stacktrace.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jun 21, 2022
@sbrannen sbrannen self-assigned this Jun 21, 2022
@sbrannen sbrannen added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jun 21, 2022
@sbrannen sbrannen added this to the 5.3.22 milestone Jun 21, 2022
@sbrannen sbrannen closed this in dbe8f20 Jun 21, 2022
@sbrannen
Copy link
Member

This has been merged into 5.3.x and main.

Thanks

@vpavic vpavic deleted the improve-logging-cache-error-handler-ctor branch June 21, 2022 12:44
sbrannen added a commit that referenced this pull request Jun 21, 2022
Since LoggingCacheErrorHandler was only recently introduced in 5.3.16,
we have decided to completely revise its internals (protected API) in
5.3.x while retaining the current public API.

Specifically, this commit:

- introduces protected getLogger() and isLogStackTraces() methods to
  improve extensibility

- revises logCacheError() to accept a Supplier<String> for lazy
  resolution of error messages

Closes gh-28672
See gh-28670, gh-28648
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

Successfully merging this pull request may close these issues.

None yet

3 participants