Wildly logging subsystem - handler to route all to log4j
nuno.godinhomatos Aug 23, 2017 12:57 PMThe use case is simple.
Imagine a jdk stand alone application - no container.
You use a couple of different libraries from A, B or C.
Some use java util logging, some use slf4j, some use log4j, some use whatever.
You want a uniform logging, you have your own special appenders for say log4j1.
You do not want to lose time migrating to log4j2 yet, it is not a problem.
So - task is easy.
You start your application the -Dlogj4j=/some/arbitrary/path/to/configurationFile.[xml|| properties], and then you add to you application cllasspath all sorts of SLF4j dependencies to JUL to SLF4j, jboss logging to slf4j, etc, until you get the slf4j to log4j.
You are set to go.
So this is the JDK scenario.
Now the problem.
Imagine you want to do exctly the same thing in wildfly.
Wildfly conveniently comes with all bindings from java util logging to wildfly log manager, log4j to wildly log manager etc..
In the end you have your subsystem logging where you can sepicy some handlers, typically something among those provided like rolling file appender.
Now, say we do not want to do this.
We really want ALL logging, not just that of some arbitrary deployment.
We want cross cutingly all logging to go log4j where you have your own special appenders.
How can we do this?
I have spotted the following guide.
Using Apache Log4j 2 as logger for WildFly 9 - Java Tipps + Tricks
It seems to be answer I am looking for.
In a phrase:
What I really want, is to get exactly the same behavior, that I would have if my application from the very begging only had as logging just with SLFJ4j as the logging infrastructure: all log to slf4j, slf4j logs to log4j, I control the log4j,xml properties where I have my own existing appenders.
Why I am skeptical about the above guide:
(a) If the handler to be implemented is a Java Util Logging to Log4j handler - than this spells disaster.
Why? Because java util logging as an API is unusable. Some examples ...
- The thread ids are integers and not long, becomming corrupted since a Thread.getThreadId() is not an integer.
- Java util logging events if I recall correctly, do not even have a thread name in there.
- Java util logging has no concept for the MDC api of Slf4j and Log4j - and an application logging with Slf4j might be adding additional metadata such as LogContext (userId) to log data to a specific dedicated file per user - as an exmaple.
All of this, does not exist in Jdk logging.
So at the API level - I simply suspect that If I have work with JDK logging it is a lost battle from the start.
(b) From what I have been able to see in a sample applciation, if have the subsytem logging enabled.
Even apache logging maps to the wildfly log manager handlers. Because the logging of
private static final org.apache.log4j.Logger LOG4J_LOGGER = org.apache.log4j.Logger
.getLogger(LongOnServerRestEndpoint.class);
I see, ends up in the server.log file - all correctly.
I undestand that jboss logging may be a superior.
But the point is, we have a universe of log4j appenders that at this point are not to be implemented log4j2 appenders or jboss logging appenders, or appenders on any other sort of logging implementation.
In short routing every log to self4j and slf4j to log4j is ideal.
And this is not be done at deployment level - but at application wide level.
So that any logging event reported by the app server is fully getting handle by these special appenders.
Therefore, is the above guide the way to go?
By using JUL there we would not be losing metadata in the transform to log4j events?
And our log4j events would not be retro feeding back to the widlfly log manager?
Many thanks for some insight into this.
I will ultimately test the above approach - but I would prefer to avoid going into a black hole.
Thanks for the help.