[FEATURE REQ] Ability to customize default LoggingPolicy()?

[knvsl]

• Goal is to expose MS-CV in logs.
• If no options are provided Chat SDK uses the default logger with log level set to info and the default LoggingPolicy() which redacts MS-CV.

Currently we can achieve this in Chat SDK by:

1. Providing a logger in the options with log level set to debug so we can see the headers
2. Providing a LoggingPolicy() in the options with "ms-cv" as an allowed header

The result is two outputs, one with ms-cv redacted the other with it shown.

The ask is if there is a way to customize the default logging policy (to allow ms-cv) instead of creating a new one?

Example of setting options for ChatClient:

let options = AzureCommunicationChatClientOptions(
                    logger: ClientLoggers.default(tag: "AzureCommunicationChatClient", level: .debug),
                    transportOptions: TransportOptions(
                        perRequestPolicies: [LoggingPolicy(allowHeaders: ["ms-cv"])]
                    )
                )
let chatClient = try ChatClient(endpoint: endpoint, credential: credential, withOptions: options)

[tjprescott]

cc/ @anuchandy how do you handle this today in Android? I am thinking that perhaps instead of passing a logger into the ClientOptions, we instead pass in LoggingOptions, which would include the logger but also let you customize the LoggingPolicy (allowHeaders, etc).

[anuchandy]

In the vnext android SDK, thinking of accepting HttpLogOptions while creating any Azure client (e.g. ChatClient). [Like you said above].

At least now, I'm not planning to take ClientLogger instance from user.

In Java/Android we've an option to wrap SLF4J-logger interface in our ClientLogger. SLF4J is a standard log FX in Java world, which provide ways to inject/change SLF4J-logger interface impl.

By default ClientLogger simply uses Android system logger, but if user ever need to switch from that system-logger then they can do it by configuring SLF4J, which changes the underlying slf4j-logger interface impl.

Taking a client ClientLogger can put us in a situation to make exact logger instance available everywhere, (may be even in models if they do validations), passing it around make code clumsy, so I thought of following what Java accepted as standard for the cases where logger needs to be swapped.

[github-actions[bot]]

Hi @knvsl, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.