Matt, 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.
-Adam On 4/12/24, 11:49 AM, "Matt Sicker" <m...@musigma.org <mailto:m...@musigma.org>> wrote: We’ve got a new proposal from Piotr on this front now which sort of emulates his suggestion for 3.x but applied to 2.x (since that doesn’t have the DI system). I like the approach there as it provides enough of a hook for users to customize whatever metrics library they wish to enhance some components however they see fit (similar to Spring’s BeanPostProcessor functionality). > On Apr 12, 2024, at 06:33, Piotr P. Karwasz <piotr.karw...@gmail.com > <mailto:piotr.karw...@gmail.com>> wrote: > > Hi Volkan, > > On Thu, 11 Apr 2024 at 21:26, Volkan Yazıcı <vol...@yazi.ci > <mailto:vol...@yazi.ci>> wrote: >> *Slightly longer answer:* Log4j has never had a holistic observability view >> to its internals. We need something new (if not, from scratch), and >> preferably, applicable to not only async. logging, but all components >> wherever this can be needed. This is time consuming hard work. >> Piotr and I, sort of, the only active Log4j maintainers nowadays, are >> swamped with other priorities. All that said, you can contract a maintainer >> <https://logging.apache.org/log4j/2.x/support.html#commercial> >> <https://logging.apache.org/log4j/2.x/support.html#commercial>> to get >> this >> rolling. > > I think you meant "you can contribute the functionality or contract > **any** developer to do it". ;-) The way you wrote it sounds horrible. > > Adam, to be entirely clear: > > * Volkan and I are **not** the only maintainers. If a majority of > maintainers support your PR, personally I will not block it, although > I prefer to keep implementation details encapsulated as much as > possible, so we can refactor them at any time, > > * We would like to have a holistic solution to instrumenting Log4j > Core. Even though Volkan and I undeniably work a lot on Log4j as part > of our job, adding metrics to Log4j is not covered by our clients. So > we cannot afford to deliver it ourselves in our spare time, > > * Volkan probably meant that a Log4j maintainer could deliver this > work faster, but we really don't care who contributes it. If you can > contribute such a PR, we would be happy to review it. However before > starting such a major endeavour you should either discuss the details > on this mailing list or you can contact us directly and we can > organize a video call with the rest of the PMC, > > * Let me stress that we treat all PRs equally, whether coming from a > project founder, PMC member or external contributors. My > co-maintainers could probably tell you more about it. ;-) > > Piotr
