At present, to get a log4j logger you call a static method on the LoggerClass.
What log4j needs, then is a "resource archive" (.RAR) and some protocols.
So I suggest the following:
Components running inside a container should access log4j by asking JNDI for the name java:comp/log4j. They MUST NOT call the static methods on LoggerClass.
JNDI will return a factory object that acts like a J2EE connection pool or a java.sql.DataSource. You "ask" this object for a Logger.
The factory object will implement, say, LoggerSource. It will have methods getLogger(), getLogger(String), and getLogger(Class).
Components MUST NOT use addAppender, callAppenders, setLevel, setPriority etc. These methods MAY throw an UnsupportedOperationException
- Component writers SHOULD copoerate with deployers to decide on contexts
Component writers SHOULD avoid the use of getLogger(Class). Instead, they should use a short context string on the understanding that it will function within a namespace provided by the LoggerSource
Now, at present we can write a connector that does nothing by call the existing Logger static methods. The important thing is to establish the use of LoggerSource and the JNDI name.
Once that is in place, then we can look at things like:
- configurators that allow one to remap output on a bean by bean basis
- configurators that redirect different EARs running in the same JVM to different places
- vendor specific configurators that do hot redirecting of logger streams, that are operated by the various vendor consoles
- Appenders and formatters that are aware of transactions
- * that "untangle" lines coming from different transactions and group them together
- * formatters that "tree structure" nested transactions
- * and that mark subtransactions that are rolled back and comitted