My current build lead has a great idea in theory - construct a custom Log4J appender that takes in Spring-managed beans and uses them to log errors to various other sources
You're going to have a boostrap problem since log4j has to be initialized before Spring. Whether you're using a custom configuration or Log4j's standard initializer, it has to be up before application context is.
Now, you could in theory make your custom appenders "lazily" initialize themselves (either via approach you've suggested above or by making appenders themselves "semi" singletons - e.g. appender class has a static instance field which gets populated by afterPropertiesSet()
method; that way you can create appender itself as bean within Spring) but it seems somewhat messy and inconsistent.
Another approach is to dynamically reconfigure Log4j once Spring context is initialized; e.g. write a listener to catch a ContextStartedEvent
, obtain all beans of type Appender
from the context and add them to Log4j configuration. This will also allow you to create your appenders as beans but avoid singleton mess somewhat.
Bit late, but I hope that this can help someone else. I've documented a solution to this issue in the answer i've provided in the following link:
log4j - Accessing spring bean from logging appender class