ppkarwasz opened a new issue, #3832:
URL: https://github.com/apache/logging-log4j2/issues/3832
The current `log4j-core-test` module includes a variety of test fixtures
primarily designed to test Log4j Core itself and its internal plugins. These
fixtures assume that:
* Static loggers (other than `StatusLogger`) are absent from the code under
test.
* A new `LoggerContext` can be created per test case.
* Loggers are created by the test cases, not the code under test.
This model works well for testing Log4j itself but breaks down in the
context of third-party libraries and applications, where:
* Loggers are typically declared as `static final` fields.
* Logger initialization might happen before the test setup, making it
impractical to substitute a different `LoggerContext` or logger instance at
runtime.
As a result, most test fixtures in `log4j-core-test` are not reusable
outside of Log4j’s own testing. The only widely useful component is
`ListAppender`, which depends solely on Log4j Core. However, to use just
`ListAppender`, developers must still depend on the entire `log4j-core-test`
module—bringing in unnecessary dependencies and potential conflicts that often
need to be manually excluded.
### Proposal
To improve the usability and modularity of Log4j test support for
third-party projects:
1. **Extract `ListAppender` into a new, standalone artifact**
This artifact would:
* Be explicitly intended for use by external libraries and applications
in testing scenarios.
* Only include minimal and broadly useful test utilities like
`ListAppender`.
* Have the same backward compatibility guarantees as Log4j Core itself.
2. **Evaluate and incorporate improvements from past community feedback**
In particular, we should revisit insights from this [dev@logging
thread](https://lists.apache.org/thread/3n9xqc132pm49w3m67zm6wnjfw6yphkq)
Specifically, we should:
* Address concerns around using `ListAppender` in parallel test
executions.
* Improve thread-safety and isolation for better test reliability.
### Benefits
Although testing log output in unit tests is sometimes seen as excessive or
even bad practice, there are specific cases where it is both justified and
valuable:
* **Audit Logging Compliance**
Verifying that audit logs are emitted correctly is crucial in systems
where traceability and accountability are required. This aligns with one of the
core purposes of Log4j Core itself.
* **Capturing Operational Details Not Exposed to Users**
In many systems, user-facing error messages are intentionally vague for
security or UX reasons. Logs often carry the detailed context needed for
debugging, so it's useful to ensure those details are reliably recorded.
* **Monitoring Failures in Background Threads**
Failures in asynchronous or background threads often can't propagate to
the main execution flow. Logging may be the *only* way these failures surface,
making it essential to validate they’re captured appropriately.
To support these use cases effectively, it's important to provide users with
a lightweight, purpose-built artifact focused solely on general logging test
utilities. This avoids the complexity and overhead of `log4j-core-test`, which
includes many features intended only for internal testing of Log4j Core itself.
--
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: notifications-unsubscr...@logging.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
