ADR: Common Logger Interface for Java
Common Logger Interface for Java
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
Today, there are several methods used for logging in the code: 1) using the JaxRsDpsLog component, 2) directly using an implementation of ILogger and 3) a log library. JaxRsDpsLog is a request scoped Spring component and can't be used in a non-request scoped context such as startup, worker type of flow (WKS), libraries, etc.
The goal is to:
-
Consolidate these logging methods to use SLF4J instead for application logging. Each cloud provider would then have the flexibility to use the appropriate logging framework for the implementation. Additionally, this eliminates the request scoped context requirement. SLF4J (Simple Logging Facade for Java) is an abstraction for various common logging frameworks such as log4j and logback.
-
Refactor JaxRsDpsLog for audit and dependency logging only.
Note: This is slightly related to ADR: Using slf4j abstraction instead of using a specific logger like log4j2 or logback or java.utils.logging. The intention of that ADR was to request consumers to use the SLF4J abstraction rather than the logging frameworks (log4j, logback) directly in the code. This Common Logger Interface for Java ADR has a wider scope and includes changes to JaxRsDpsLog.
Decision
- Update existing code to use SLF4J abstraction for application logging.
- Refactor JaxRsDpsLog to only log audits and dependencies among services.
Rationale
- To provide a common and standard logging abstraction to support logging needs.
- Allow cloud provider flexibility to use logging framework of choice.
- Eliminates request scoped requirement that is present when using JaxRsDpsLog.
Consequences
Consumers/cloud providers will need to migrate to using the refactored JaxRsDpsLog and SLF4J abstraction as needed. If the default logger does not suffice, consumers/cloud providers will need to add their own implementation.
Impacted Services
The list of services below reference ILogger or JaxRsDpsLog:
-
os-core-common (WIP) -
data-workflow -
dataset-registry -
delivery -
file -
indexer-queue -
ingestion-service -
ingestion-workflow -
legal (MR Draft) -
notification -
partition -
register -
schema-service -
search-service -
storage
We will update the core code of each services one at a time to use SLF4J directly for application logging.
Tradeoff Analysis - Input to decision
As we progress to production readiness, a common and standard logger interface will prevent additional workarounds that is being used today for code that does not meet the requirements to use JaxRsDpsLog. Cloud service providers have the flexibility to pick which logging framework to use.
Decision criteria and tradeoffs
Decide whether to use SLF4J abstraction for application logging. Decide whether to refactor JaxRsDpsLog for audit and dependency logging only.