3.2 KiB
name, group, category, update-time, description, key-word
| name | group | category | update-time | description | key-word | ||||
|---|---|---|---|---|---|---|---|---|---|
| library-async-logger-with-target | api | facade | 20260614 | Replace the default target carried by a LibraryAsyncLogger facade while rewrapping the derived async logger state behind the same library-facing surface. |
|
Library-async-logger-with-target
Replace the default target on a LibraryAsyncLogger[S]. This is the library-facing counterpart to AsyncLogger::with_target(...) when package code wants to retarget an async logger without exposing the full async logger API.
Interface
pub fn[S] LibraryAsyncLogger::with_target(
self : LibraryAsyncLogger[S],
target : String,
) -> LibraryAsyncLogger[S] {
input
self : LibraryAsyncLogger[S]- Base facade whose default target should be replaced.target : String- New default target namespace.
output
LibraryAsyncLogger[S]- New library-facing async facade carrying the updated target.
Explanation
Detailed rules explaining key parameters and behaviors
- This API delegates to the wrapped async logger's
with_target(...)behavior and then re-wraps the result as anotherLibraryAsyncLogger[S]. - The original facade is not mutated. The returned facade stores the replacement target while the source facade keeps its previous target.
- Timestamp behavior, enabled-level gating, sink type, queue state, async config, and failure/lifecycle state stay the same because only the default target field changes.
- This replaces the default target instead of composing it.
- Async state helpers remain hidden behind the narrower facade after rewrapping; use
to_async_logger()if later code needs them.
How to Use
Here are some specific examples provided.
When Need A New Fixed Async Namespace Inside Library Code
When one facade should emit under a different async target namespace:
let logger = LibraryAsyncLogger::new(@bitlogger.console_sink())
.with_target("sdk.http")
In this example, later async writes inherit sdk.http unless a call overrides the target directly.
When Reuse One Async Setup Across Library Subsystems
When multiple library-facing async loggers should share one queue policy:
let base = LibraryAsyncLogger::new(
@bitlogger.console_sink(),
config=AsyncLoggerConfig::new(max_pending=64),
)
let cache = base.with_target("cache")
let io = base.with_target("io")
In this example, one base facade becomes several target-specific async facades.
And each derived facade still wraps the same kind of queue-backed async logger state, differing only in the default target it carries.
The derived facade keeps the same timestamp and level-gating behavior as the source facade.
Error Case
e.g.:
-
If
targetis empty, the returned logger remains valid and later records simply use an empty default target. -
If callers need hierarchical target composition rather than replacement,
child(...)is the better API.
Notes
-
Use this API for replacement, not target-path composition.
-
It keeps the narrower
LibraryAsyncLoggerboundary intact. -
Use
child(...)when the new target should be combined with the current one instead of replacing it.