This setup should work for us. While we don’t control logging initialization, we will reliably be present on the classpath at initialization time, and ServiceLoader should have no problems finding our implementation.
> You probably want to implement a "push" counter for the discarded messages, > so you get notified immediately whenever a discard event occurs? For my use-case, no, periodic reporting is fine, but I'm happy to do the batching on my end. -Adam On 4/12/24, 2:50 PM, "Piotr P. Karwasz" <piotr.karw...@gmail.com <mailto:piotr.karw...@gmail.com>> wrote: Hi Adam, On Fri, 12 Apr 2024 at 21:42, Thomas, Adam <adamt...@amazon.com.inva <mailto:adamt...@amazon.com.inva>lid> wrote: > That sounds appealing, but do you have to have this hook registered by the > time the disruptor is set up? That's my fundamental concern with a lot of > these interception strategies - if your library/framework is called (which > ours is), instead of being the entry point (as many others often are), > logging will most likely already be initialized by the time control is handed > to you. By the time my code gets a chance to inspect the LoggerContext, log4j > has already decided which policy to use, instantiated it, and installed it. My draft proposal[1] uses `ServiceLoader` to load all available `InstrumentationService` implementations, so it happens before the creation of the first `Logger` and the `AsyncLoggerDisruptor`. We could obviously develop a system to allow late registrations of `InstrumentationService`. Most of the components I expose in the PR are tied to a `Configuration` so triggering a reconfiguration could allow your code to instrument most of them. Unfortunately the list does not include the `MessageFactory` used by already created loggers or the disruptor attached to `AsyncLoggerContext` (but it includes the disruptor used by `AsyncLoggerConfig`s). You probably want to implement a "push" counter for the discarded messages, so you get notified immediately whenever a discard event occurs? Feel free to comment on the PR or branch the code to correct it. Piotr [1] https://github.com/apache/logging-log4j2/pull/2469 <https://github.com/apache/logging-log4j2/pull/2469>
