Specify behavior of `LoggingAdmin.getInstance()`

[ppkarwasz]

The current design of LoggingAdmin.getInstance() requires a token, conceptually similar to Tomcat’s ContextBindings.bindContext. This token mechanism was introduced to prevent libraries from unintentionally overriding an application’s logging configuration.

Limitations of the Current Approach

This token-based protection is inherently opt-in, which makes it unreliable. Libraries can—and often do—interact directly with the underlying logging framework (e.g., Logback, Log4j2). As a result, the intended protection is easily circumvented, especially in environments where multiple applications or libraries share a common logging context.

Proposed Direction

To create a more effective and resilient mechanism, we should consider shifting away from opt-in tokens toward a cooperative, classloader-aware model. For example, the logging system could expose metadata indicating whether the logger context is scoped:

• Per web application (isolated)
• Globally (shared across apps)

This information would enable frameworks like Spring Boot to detect shared contexts and conditionally disable logging auto-configuration to avoid overriding the shared settings.

Goals

• Eliminate reliance on opt-in tokens for logging protection
• Support classloader-aware logging context scoping
• Enable frameworks to behave appropriately in shared vs. isolated environments