> All you need is a `log4j2.component.properties` file in your library. It is very common practice here to explicitly specify the discard policy as a system property, as it was recommended to teams moving from log4j1 to log4j2. Adding this would have very little impact.
> 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. I can cope with different log4j versions having different ways to discover metrics, I understand a major version increase is likely to be disruptive. I also completely understand not wanting to add this as a first-class property of `LoggerContext`. Would publishing this value via JMX be more palatable? I believe you've removed JMX from 3.x, so this hopefully would not collide with whatever instrumentation you decided to backport to 2.x. -Adam On 4/10/24, 10:42 AM, "Piotr P. Karwasz" <piotr.karw...@gmail.com <mailto:piotr.karw...@gmail.com>> wrote: Hi Adam, On Wed, 10 Apr 2024 at 19:03, Thomas, Adam <adamt...@amazon.com.inva <mailto:adamt...@amazon.com.inva>lid> 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 <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
