Pil0tXia opened a new pull request, #4698:
URL: https://github.com/apache/eventmesh/pull/4698
<!--
### Contribution Checklist
- Name the pull request in the form "[ISSUE #XXXX] Title of the pull
request",
where *XXXX* should be replaced by the actual issue number.
Skip *[ISSUE #XXXX]* if there is no associated github issue for this
pull request.
- Fill out the template below to describe the changes contributed by the
pull request.
That will give reviewers the context they need to do the review.
- Each pull request should address only one issue.
Please do not mix up code from multiple issues.
- Each commit in the pull request should have a meaningful commit message.
- Once all items of the checklist are addressed, remove the above text and
this checklist,
leaving only the filled out template below.
(The sections below can be removed for hotfixes of typos)
-->
<!--
(If this PR fixes a GitHub issue, please add `Fixes #<XXX>` or `Closes
#<XXX>`.)
-->
Fixes #4697.
### Background Knowledge
Disscussion: https://github.com/apache/logging-log4j2/discussions/2133
The additional `isDebugEnabled()` check before `log.debug()` is performed in
order to avoid invoking the methods referenced in the `message` field, thus
improving logging performance. For example:
```java
log.debug("formatted msg: {}", formatMsg(rawMsg));
```
Even when the log level is set to `info`, the `formatMsg(rawMsg)` method
will still be called and return a result before being passed as an argument to
`log.debug()`. This takes time.
### Solution Selection
Since slf4j does not support passing arguments through the Supplier
introduced in log4j 2.13.0 (discussed in
https://github.com/qos-ch/slf4j/pull/70, no need to read though), we will not
adopt the solution of lazy invocation by passing the Supplier parameter.
Additionally, the usage of the Supplier appears redundant, and most
contributors cannot understand the difference between using a Supplier or not
without prior knowledge.
The [Fluent Logging API](https://www.slf4j.org/manual.html#fluent) since
slf4j 2.0.0 provides a more elegant and space-saving way of writing code.
>Fluent Logging API is backward-compatible. The atTrace(), atDebug(),
atInfo(), atWarn() and atError() methods, all new in the org.slf4j.Logger
interface, return an instance of
[LoggingEventBuilder](https://www.slf4j.org/apidocs/org/slf4j/spi/LoggingEventBuilder.html).
For disabled log levels, the returned LoggingEventBuilder instance does
nothing, thus preserving the nanosecond level performance of the traditional
logging interface.
The modifications to the `WatchFileManager` class demonstrate the
recommended approach.
### Scenarios where Fluent Logging API is unnecessary
Only the scenario mentioned in the Background Knowledge section require the
use of Fluent Logging API. For example, in the case of the changes in `Codec`
class L224, where no object parameters are passed or existing objects are
referenced, there is no additional performance overhead, and there is no need
to pre-evaluate log levels. The simplest usage of slf4j can be directly applied.
### Follow-up tasks
After adopting Fluent Logging API, there is no need to keep `LogUtils`.
Going forward, @scwlkq will submit a PR for the unified modification of log
output statements.
### Documentation
- Does this pull request introduce a new feature? (yes)
- If yes, how is the feature documented? (not applicable)
- If a feature is not applicable for documentation, explain why?
https://www.slf4j.org/manual.html#fluent
- If a feature is not documented yet in this PR, please create a followup
issue for adding the documentation
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
