Hi Adam, On Fri, 12 Apr 2024 at 21:42, Thomas, Adam <adamt...@amazon.com.invalid> 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
