Skip to content

Specify behavior of LoggingAdmin.getInstance() #1

@ppkarwasz

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions