naloveyuki/BitLogger
1
0
Fork 0
mirror of https://github.com/Nanaloveyuki/BitLogger.git synced 2026-07-31 15:34:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

📝 refine config entry docs

Browse Source
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
Download Patch File Download Diff File Expand all files Collapse all files
docs/api/build-logger.md
+4 -1
View File
@@ -33,9 +33,10 @@ pub fn build_logger(config : LoggerConfig) -> ConfiguredLogger {}
Detailed rules explaining key parameters and behaviors 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]`. - 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. - 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. - This API is deterministic and data-driven, making it suitable for bootstrapping from parsed config.
### How to Use ### How to Use
@@ -83,3 +84,5 @@ e.g.:
2. Use `parse_and_build_logger(...)` when the starting point is raw JSON text. 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.
docs/api/parse-and-build-logger.md
+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 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. - 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. - 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. - Errors are surfaced as `ConfigError` rather than silent fallback.
### How to Use ### 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. 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.