ppkarwasz commented on PR #3839: URL: https://github.com/apache/logging-log4j2/pull/3839#issuecomment-3219871039
My idea for the proposed method ```java public Configuration getConfiguration(LoggerContext context, String name, List<URI> uris) ``` is to encapsulate the logic currently in `ConfigurationFactory.Factory`: https://github.com/apache/logging-log4j2/blob/769b9249176b69ad4474fc4bd831dec67775c953/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java#L381-L402 This would allow each `ConfigurationFactory` to support building a composite configuration from multiple URIs and will allow Spring Boot to specify the URI of the overrides, without any knowledge of Log4j's composite configuration. One open question is how to define the nullability/return contract. The existing single-URI overload, ```java public Configuration getConfiguration(LoggerContext context, String name, URI uri) ``` has inconsistent behavior across implementations: * Individual `ConfigurationFactory` implementations typically return `null` if the URI itself is `null`. * `ConfigurationFactory.Factory`, however, falls back to a `DefaultConfiguration`. Most (but not all) callers explicitly check for `null`, so the contract is somewhat unclear. For the new multi-URI variant, we should decide whether the method is allowed to return `null`, or whether it must always return a valid `Configuration` (possibly default). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
