ppkarwasz commented on issue #2106: URL: https://github.com/apache/logging-log4j2/issues/2106#issuecomment-1884723524
Regarding `ParameterizeMessage`, it must remain, since it is immutable and `ReusableParameterizedMessage#memento()` returns this type. However the recycler is only used here: https://github.com/apache/logging-log4j2/blob/b338d0764a62d591928e7f79377fd259c2d3c5c3/log4j-api/src/main/java/org/apache/logging/log4j/message/ParameterizedMessage.java#L185-L196 where it can easily be replaced by `new StringBuilder()`. It doesn't really matter if the method has one or two allocations. As far as I can see, `DefaultLogBuilder` only uses a `Recycler`, it does not need a `RecyclerFactory`. The main problem is `AbstractLogger`, since we need to look at how it is used in all three implementations. ## `log4j-to-slf4j` `log4j-to-slf4j` has its own implementation of `LogBuilder` that does not extend `DefaultLogBuilder` and it doesn't use `AbstractLogger#recycler` at all. It has its own `Recycler<Slf4jLogBuilder>` field. As I remarked in #2104, for this implementation we should analyze how it works with Logback to provide a similar experience to Log4j API/Logback and SLF4J/Logback users. When used with SLF4J's `atLevel` methods, Logback: - allocates a new `DefaultLoggingEventBuilder` if the level is allowed, - reuses a no-op builder if it is not. I submitted [LOGBACK-1719](https://jira.qos.ch/browse/LOGBACK-1719) to change this behavior and it has been resolved, but I don't see any changes in the code (maybe you can find them). Currently, when used with Log4j API's `atLevel` methods, `log4j-to-slf4j` + Logback: - use a recycled `Slf4jLogBuilder`, - use a possibly recycled `Message` (it depends on the message factory of course), - formats the `Message` (causing an allocation or two ;-) ), - calls the classic SLF4J API. We don't provide a no-op path as a fix to [LOG4J2-3647](https://issues.apache.org/jira/browse/LOG4J2-3647). If we remove the recyclers performance might suffer and much more garbage will be generated, although I don't think Logback users care about that. ## `log4j-to-jul` `log4j-to-jul` simply reuses the logic from `AbstractLogger`. If we remove recyclers, we might harm JBoss LogManager users (which extends JUL's LogManager), although they rather use the Log4j API-to-JBoss Logging bridge. ## Proposition I think that this feature enhancement is strictly linked with #2172. If we provide a light `log4j-plugins-api` artifact, you could move recyclers to their own artifact instead of including them in `log4j-core`. -- 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]
