Migrate manual files to logging abstraction#742
Conversation
e07eca3 to
b52d9a0
Compare
b52d9a0 to
429b118
Compare
Range-diff: stack/logging-jul (b52d9a0 -> 429b118)
Reproduce locally: |
429b118 to
6ea8c92
Compare
Range-diff: stack/logging-jul (429b118 -> 6ea8c92)
Reproduce locally: |
6ea8c92 to
9538f13
Compare
Range-diff: stack/logging-jul (6ea8c92 -> 9538f13)
Reproduce locally: |
9538f13 to
b9a1c3e
Compare
Range-diff: stack/logging-jul (9538f13 -> b9a1c3e)
Reproduce locally: |
b9a1c3e to
ef19539
Compare
ef19539 to
d5c03d4
Compare
d5c03d4 to
b8920e0
Compare
## 🥞 Stacked PR Use this [link](https://github.com/databricks/databricks-sdk-java/pull/740/files) to review incremental changes. - [**stack/logging-abstraction**](#740) [[Files changed](https://github.com/databricks/databricks-sdk-java/pull/740/files)] - [stack/logging-jul](#741) [[Files changed](https://github.com/databricks/databricks-sdk-java/pull/741/files/5156924f..c04a3808)] - [stack/logging-migration](#742) [[Files changed](https://github.com/databricks/databricks-sdk-java/pull/742/files/c04a3808..d5c03d4f)] --------- ## Summary Introduces a logging abstraction layer (`com.databricks.sdk.core.logging`) that decouples the SDK's internal logging from any specific backend. SLF4J remains the default. This PR contains only the abstraction and the SLF4J backend; the JUL backend and the call-site migration follow in stacked PRs. ## Why The SDK currently imports `org.slf4j.Logger` and `org.slf4j.LoggerFactory` directly in every class that logs. This hard coupling means users who embed the SDK in environments where SLF4J is impractical (e.g. BI tools with constrained classpaths) have no way to switch to an alternative logging backend like `java.util.logging`. We need an indirection layer that lets users swap the logging backend programmatically while keeping SLF4J as the zero-configuration default so that existing users don't have to change anything. The design follows the pattern established by SLF4J itself and [Netty's `InternalLoggerFactory`](https://netty.io/4.1/api/io/netty/util/internal/logging/InternalLoggerFactory.html): an `ILoggerFactory` interface that backends implement, a `LoggerFactory` utility class with static `getLogger` / `setDefault` methods, and a separate `Logger` abstract class that serves as a clean extension point for custom implementations. ## What changed ### Interface changes - **`Logger`** — new abstract class in `com.databricks.sdk.core.logging`. Defines the logging contract: `debug`, `info`, `warn`, `error` (each with plain-string, varargs, and `Supplier<String>` overloads). Users extend this to build custom loggers. - **`ILoggerFactory`** — new interface. Backends implement `createLogger(Class<?>)` and `createLogger(String)` to produce `Logger` instances. Users implement this to provide a fully custom logging backend. - **`LoggerFactory`** — new `final` utility class. Static methods `getLogger(Class<?>)` and `getLogger(String)` return loggers from the current default factory. `setDefault(ILoggerFactory)` overrides the backend — must be called before creating any SDK client. - **`Slf4jLoggerFactory`** — public concrete `ILoggerFactory` implementation with a singleton `INSTANCE`. This is the default. ### Behavioral changes None. SLF4J is the default backend and all logging calls pass through to `org.slf4j.Logger` exactly as before. Existing users see no difference. ### Internal changes - **`Slf4jLogger`** — package-private class that delegates all calls to an `org.slf4j.Logger`. Fully qualifies `org.slf4j.LoggerFactory` references to avoid collision with the SDK's `LoggerFactory`. - All new classes live in `com.databricks.sdk.core.logging`. ## How is this tested? - `LoggerFactoryTest` — verifies the default factory is SLF4J, that `setDefault(null)` is rejected, and that `getLogger(String)` works. - `Slf4jLoggerTest` — verifies `LoggerFactory.getLogger` returns the correct type, exercises all logging methods including varargs and trailing Throwable via a capturing Log4j appender that asserts on message content, level, and attached throwable. - Full test suite passes.
b8920e0 to
2370a96
Compare
Range-diff: stack/logging-jul (b8920e0 -> 2370a96)
... (truncated, output exceeded 60000 bytes) Reproduce locally: |
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
🥞 Stacked PR
Use this link to review incremental changes.
Summary
Migrates all manually-maintained source files from direct
org.slf4jimports to the SDK's logging abstraction (com.databricks.sdk.core.logging). After this PR, no hand-written file in the SDK references SLF4J directly — all logging goes through the abstraction introduced in PR #740.Why
PRs #740 and #741 introduced the logging abstraction and the JUL backend, but every existing call site still imported
org.slf4j.Loggerandorg.slf4j.LoggerFactorydirectly. Until those imports are rewritten, users cannot actually swap the logging backend — the abstraction would be dead code.This PR completes the migration for all manually-maintained files. Auto-generated files are left unchanged and will be addressed separately via codegen updates.
What changed
Interface changes
None.
Behavioral changes
None. All logging calls pass through the abstraction layer, which defaults to SLF4J. Existing users see no difference.
Internal changes
org.slf4j.Logger/org.slf4j.LoggerFactoryimports are replaced withcom.databricks.sdk.core.logging.Logger/com.databricks.sdk.core.logging.LoggerFactory. No other code changes — theLoggerAPI is identical.core,core.oauth,core.retry,core.utils,core.error,core.commons, andmixinpackages.ApiClientrequest/response log now usesLOG.debug(() -> makeLogRecord(in, resp))(theSupplier<String>overload) instead of an explicitisDebugEnabled()guard, since the abstraction handles the guard internally.How is this tested?
Loggerabstraction exposes the samedebug/info/warn/errormethods asorg.slf4j.Logger.