📝 refine config entry docs

This commit is contained in:
Nanaloveyuki
2026-06-14 01:36:33 +08:00
parent bf545b0e0c
commit 8bf6ec8f52
2 changed files with 8 additions and 2 deletions
+4 -1
View File
@@ -33,9 +33,10 @@ pub fn build_logger(config : LoggerConfig) -> ConfiguredLogger {}
Detailed rules explaining key parameters and behaviors
- `build_logger(...)` constructs the runtime sink shape based on `SinkConfig` and optional queue wrapper.
- `build_logger(...)` first constructs a base `RuntimeSink` from `config.sink`, then applies `config.queue` when present, and finally builds `Logger::new(...)` with `config.min_level`, `config.target`, and `config.timestamp`.
- The returned logger still supports normal logging methods because `ConfiguredLogger` is `Logger[RuntimeSink]`.
- Queue metrics and file controls remain available through forwarding helpers on the configured logger.
- `build_application_logger(...)` only re-exports this same configured runtime logger result under the `ApplicationLogger` alias, while `build_library_logger(...)` wraps the same result in `LibraryLogger[RuntimeSink]`.
- This API is deterministic and data-driven, making it suitable for bootstrapping from parsed config.
### How to Use
@@ -83,3 +84,5 @@ e.g.:
2. Use `parse_and_build_logger(...)` when the starting point is raw JSON text.
3. Use the application or library facade builders only when the boundary name or exposed surface should differ; they do not change the underlying configured runtime logger pipeline built here.
+4 -1
View File
@@ -33,9 +33,10 @@ pub fn parse_and_build_logger(input : String) -> ConfiguredLogger raise ConfigEr
Detailed rules explaining key parameters and behaviors
- Parsing and building are done in one step, which is useful when you do not need to inspect the intermediate `LoggerConfig`.
- Parsing and building are done in one step by calling `parse_logger_config_text(input)` first and then passing the resulting `LoggerConfig` into `build_logger(...)`.
- The returned `ConfiguredLogger` is just `Logger[RuntimeSink]`, so it still supports regular logging calls.
- Queue wrapping and file control helpers remain available after config assembly.
- `parse_and_build_application_logger(...)` only re-exports this same configured runtime logger result under the `ApplicationLogger` alias, while `parse_and_build_library_logger(...)` wraps the same result in `LibraryLogger[RuntimeSink]`.
- Errors are surfaced as `ConfigError` rather than silent fallback.
### How to Use
@@ -86,3 +87,5 @@ e.g.:
2. Prefer this API for app bootstrapping paths that read config once and then construct the runtime logger.
3. Use the application or library parse/build facades only when the public name or exposed surface should differ; they do not change the configured runtime logger pipeline produced here.