Pil0tXia commented on issue #4697:
URL: https://github.com/apache/eventmesh/issues/4697#issuecomment-1872927092
I have reviewed all the logs in EventMesh, most of them involve object
references, a few of them being string operations. and few time-consuming
methods. However, the main drawback of the Fluent Logging API is that, in terms
of simplicity, it is not only inferior to LogUtils but even less so than the
original usage with `isDebugEnabled`.
For this section of code in `TcpClient`:
```java
if (log.isDebugEnabled()) {
LogUtils.debug(log, "close tcp client failed.|remote address={}",
channel.remoteAddress(), e);
}
```
The Fluent Logging API would require the following:
```java
log.atDebug().setMessage("close tcp client failed.|remote address={}")
.addArgument(() -> channel.remoteAddress())
.setCause(e).log();
```
In terms of both lines of code and readability, it is not as favorable as
the former.
However, with LogUtils, you can write it as follows:
```java
LogUtil.debug(log, "close tcp client failed.|remote address={}", () ->
channel.remoteAddress(), e);
```
@pandaapo The existing issue with LogUtils is excessive wrapping and being
too bulky. I would remove LogUtils' wrapping for all slf4j normal usage and
redundant `isDebugEnabled` checks, then retain only the methods with Supplier
(lambda expression) parameters. What do you think of this approach?
--
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]
