Async-logger-build-config-to-json

Convert AsyncLoggerBuildConfig into a JsonValue. This helper exports both the base synchronous logger config and the async runtime config as one structured payload.

Interface

pub fn async_logger_build_config_to_json(
  config : AsyncLoggerBuildConfig,
) -> @json_parser.JsonValue {}

input

• config : AsyncLoggerBuildConfig - Complete build config used by async logger builders.

output

• JsonValue - Structured JSON representation of the full async build config.

Explanation

Detailed rules explaining key parameters and behaviors

• The output always includes logger and async_config.
• Logger export is delegated to @bitlogger.logger_config_to_json(...).
• Async export is delegated to async_logger_config_to_json(...).
• Because both sections are always materialized, parsed defaults that were originally omitted in JSON input become explicit again in the exported build-config shape.
• This helper is useful when generated setup should preserve both sink/logger behavior and async runtime behavior together.
• The exported logger section keeps the full LoggerConfig shape, including fields that only matter on the full sync-first builder path such as the optional sync queue layer.
• That means the JSON shape is broader than the consumption pattern of build_async_text_logger(...), which only uses selected text-oriented logger fields when building the sink.
• In particular, the exported logger.sink.kind remains whatever the config currently says, but a later build_async_text_logger(...) call still ignores that sink-kind branch and constructs FormattedConsoleSink from logger.sink.text_formatter.
• The same exported object is also the shared handoff shape for the application and library facade routes after parse. parse_async_logger_build_config_text(...) can read this JSON back into AsyncLoggerBuildConfig, and that parsed value can then flow unchanged into build_application_async_logger(...), build_application_text_async_logger(...), build_library_async_logger(...), or build_library_async_text_logger(...).
• Because of that, the exported structure is descriptive config data rather than a commitment to one public async type. The later builder or facade API still decides whether the runtime-sink line or the text-console line is taken.

How to Use

Here are some specific examples provided.

When Need Structured Export Of Full Async Setup

When a tool or test needs one object describing the whole async logger build:

let payload = async_logger_build_config_to_json(
  AsyncLoggerBuildConfig::new(
    logger=@bitlogger.LoggerConfig::new(target="svc"),
    async_config=AsyncLoggerConfig::new(max_pending=64),
  ),
)

In this example, both layers of configuration are exported together.

And later consumers can still choose whether to rebuild through build_async_logger(...) or the narrower build_async_text_logger(...) path.

And that later text-specific builder choice still matters more than the serialized logger.sink.kind value, because only the formatter-backed text path is consumed there.

And the same exported object can just as well be parsed and then routed into the application or library facade builders when the next consumer wants a narrower public async type.

When Need Roundtrip-friendly Build Config Data

When generated build config should later be parsed again:

let value = async_logger_build_config_to_json(AsyncLoggerBuildConfig::new())

In this example, the resulting JSON matches the supported async build config shape.

Error Case

e.g.:

• If callers only need the async runtime section, this API is broader than necessary and async_logger_config_to_json(...) should be used instead.

• If callers want direct text output, they should use stringify_async_logger_build_config(...) instead.

• Exporting the full logger section does not imply that every async builder will later consume every logger field equally.

• Exporting logger.sink.kind="file" or "console" also does not force the later text-specific builder path to branch that way; only build_async_logger(...) follows sink kind when constructing the runtime sink.

• Choosing an application or library facade builder later does not change the meaning of the exported config by itself; those facade APIs inherit the same runtime-sink-versus-text-console split from the direct builder they delegate to.

Notes

1. Use this helper when tools or tests need a structured JSON object instead of text.

2. Use stringify_async_logger_build_config(...) when the same build shape should be emitted as JSON text directly.

3. The resulting object round-trips through parse_async_logger_build_config_text(...), even though different async builders later consume different parts of the embedded LoggerConfig.

4. After parsing, that same object can also feed the application or library facade builders; export preserves one shared build-config shape, not a direct-builder-only route.