switch logger to golang.org/x/exp/slog about weaver HOT 2 CLOSED

Could you please provide a bit more detail on why this was closed? Specifically, I think it could help to clarify how slog integration is not possible. From where I sit, the necessity of intercepting all logs does not preclude using slog, and I have an internal service library implementation that does exactly this via a common logging interface, while also providing access to creating new handlers through a well-defined interface layer. What's to prevent ServiceWeaver from adopting a similar approach? If you enumerate the difficulties or concerns, it could serve as a useful starting point for a PR from someone with experience integrating the slog package. At the very least, this issue could serve as a guideline for exactly why slog can't be used, and could be linked from the documentation to prevent any further issues or PR requests.

Given that slog is intended to serve as a stdlib-standard interface to structured logging, would you consider reopening this issue until the proposal lands? Maybe change the issue title to something like "Investigate integrating the proposed slog package"

from weaver.

Thanks for reporting.

Our logger API is based on the slog api. However, our logger needs to intercept all the logs, in order to store them in the appropriate logs storage (e.g., Google Cloud Logging, local files). So we can't use the slog package directly.

from weaver.