Hi Adam, On Wed, 10 Apr 2024 at 19:03, Thomas, Adam <adamt...@amazon.com.invalid> wrote: > I would do this if I had control of the end user's logging setup. > Unfortunately, I vend an internal library that is used by a lot of different > teams. By the time my code is invoked, AsyncLoggerDisruptor has already read > the system property and initialized the queue full policy. For other log4j > telemetry I just programmatically inspect the LoggerContext when my code > initializes, and install a property change listener to listen for > configuration changes. Even if I vend my own custom AsyncQueueFullPolicy, > practically speaking I will never get very good coverage, because I would > have to go convince thousands of developers to change their system properties.
Log4j supports multiple property sources, not only Java system properties: https://logging.apache.org/log4j/2.x/manual/configuration#SystemProperties All you need is a `log4j2.component.properties` file in your library. Regarding your original PR, we are working hard to reach a definitive Log4j Core 3.x version. Once that is achieved, we can propose a way to get metrics that will work in both 2.x and 3.x. Until then I am afraid that all libraries that propose metrics and traces in Log4j Core will need to have specific version for each release. Piotr
