4.1 KiB
name, group, category, update-time, description, key-word
| name | group | category | update-time | description | key-word | ||||
|---|---|---|---|---|---|---|---|---|---|
| build-library-async-text-logger | api | facade | 20260614 | Build the library-facing text-console async logger facade from an AsyncLoggerBuildConfig using the concrete text-console builder path. |
|
Build-library-async-text-logger
Build a LibraryAsyncLogger[FormattedConsoleSink] from AsyncLoggerBuildConfig. This facade is the library-oriented async builder for the concrete text-console sink shape returned by build_async_text_logger(...).
Interface
pub fn build_library_async_text_logger(
config : AsyncLoggerBuildConfig,
) -> LibraryAsyncLogger[FormattedConsoleSink] {
input
config : AsyncLoggerBuildConfig- Combined sync logger config and async queue/runtime config.
output
LibraryAsyncLogger[FormattedConsoleSink]- Library-facing async logger backed by formatted console output.
Explanation
Detailed rules explaining key parameters and behaviors
- This API delegates to
build_async_text_logger(...)and then narrows the result toLibraryAsyncLogger[@bitlogger.FormattedConsoleSink]. - It always produces a concrete
FormattedConsoleSinkfromconfig.logger.sink.text_formatterinstead of branching on sink kinds. - Unlike
build_library_async_logger(...), this facade does not go through the full synchronous configured-logger build path first. - It uses the selected text-oriented
LoggerConfigfields directly and therefore does not applyLoggerConfig.queueor preserve sync runtime sink controls. - A sync queue configured on
LoggerConfig.queueis therefore ignored by this builder instead of being preserved behind the wrapped text-console async logger. - The returned facade wraps the same underlying
AsyncLogger[@bitlogger.FormattedConsoleSink]value thatbuild_async_text_logger(...)would return directly, sorun(),shutdown(), failure/reset handling, and runtime-dependent close behavior are unchanged under the narrower public type. - Async state helpers such as
pending_count(),dropped_count(),state(),wait_idle(), and failure-status inspection remain on the underlyingAsyncLogger[@bitlogger.FormattedConsoleSink], not on the returned facade itself. to_async_logger()can recover the underlying full async logger if needed.- Use this builder when the boundary should preserve the concrete text-console sink type while still hiding broader async inspection and helper APIs from downstream callers.
How to Use
Here are some specific examples provided.
When Need A Narrow Async Text Logger For Libraries
When a library wants text-console async output and a narrower public type:
let logger = build_library_async_text_logger(
AsyncLoggerBuildConfig::new(
logger=text_console(target="lib.text.async"),
async_config=AsyncLoggerConfig::new(max_pending=4),
),
)
In this example, the async text sink shape is preserved under the library facade.
When Need Async State Helpers After Library Text Construction
When library-facing text-console construction should still allow internal async inspection later:
let logger = build_library_async_text_logger(config)
let full = logger.to_async_logger()
ignore(full.pending_count())
In this example, the facade is unwrapped before using async state helpers.
Error Case
e.g.:
-
If callers need sink-kind-driven branching such as JSON console or file-backed async output, they should use
build_library_async_logger(...)instead. -
If callers expect async state or idle-wait helpers directly on the returned facade, they must unwrap first with
to_async_logger(). -
Normal async lifecycle expectations still apply if the logger is never run.
Notes
-
This is the library-side counterpart to
build_application_text_async_logger(...). -
It is most useful when a concrete text-console async sink type matters to the caller boundary.
-
Use
build_library_async_logger(...)instead when the library-facing async type should keep the broaderRuntimeSinkbuild path, including sync queue application throughbuild_logger(config.logger).