Create a standalone artifact for non-internal test fixtures

[ppkarwasz]

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
   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.