GitHub user ppkarwasz added a comment to the discussion: Help with migrating from log4j to log4j2 (we also use a slf4j -> log4j)
Hi @paladox, The `SshLog` class is trickier to migrate because Log4j 2 introduces features designed specifically for cases like audit logging. The approach from Log4j 1.x (manually constructing `LoggingEvent`s and pushing them directly into appenders) is no longer the only or the best option. You bind yourself to the specific logging implementation, while everything could be done through the logging API. Here are a few points to consider: - **Custom messages** In Log4j 1.x you were limited to logging plain strings, which is why the original code dipped into internals and built `LoggingEvent` objects by hand. In Log4j 2 you can define [custom `Message`](https://logging.apache.org/log4j/2.x/manual/messages.html) implementations that encapsulate structured audit data. Gerrit’s `AuditEvent` looks like a good candidate to implement `Message` (or one of its sub-interfaces), so you can pass it directly to the logger instead of bypassing it. This way you keep control on the formatting of the message, while delegate routing and filtering to the logging implementation. @rgoers can tell you more on how to use custom messages for auditing purposes. - **Markers** For categorization, use [Markers](https://logging.apache.org/log4j/2.x/manual/markers.html). For example, successful logins might only be `INFO`-level, but marking them with `SECURITY` or `AUDIT` allows you to send them to a dedicated audit log file using a [`MarkerFilter`](https://logging.apache.org/log4j/2.x/manual/filters.html#MarkerFilter). - **Asynchronous logging** I would be cautious about using asynchronous appenders for audit logs. Audit trails are mission-critical: if the appender fails, you *want* the logging thread to throw so you know something went wrong. That means: 1. Use an appender with `ignoreExceptions="false"` so errors throw instead of ending in the status logger. 2. Prefer a synchronous appender for audit logs and use asynchronous appenders only for non mission-critical log events. I am not convinced Gerrit needs asynchronous logging, as this is usually needed to reduce **latency**. See the [trade-offs of async logging](https://logging.apache.org/log4j/2.x/manual/async.html) in our documentation. If you really need async behavior, prefer [`AsyncLogger`](https://logging.apache.org/log4j/2.x/manual/async.html), which shifts almost all work to the background thread and is more efficient than the classic [`AsyncAppender`](https://logging.apache.org/log4j/2.x/manual/appenders/delegating.html#AsyncAppender). GitHub link: https://github.com/apache/logging-log4j2/discussions/3914#discussioncomment-14330469 ---- This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
