Rather than the printing the mesage via LogLog.error(...) 229 /** 230 * Rather than log an ugly stack trace, output the msg 231 */ 232 LogLog.error(msg + "(" + e.getMessage() + ")"); use 232 LogLog.info(msg + "(" + e.getMessage() + ")"); or 232 LogLog.debug(msg + "(" + e.getMessage() + ")"); ...just like done in the SocketAppender$Connector class. IMHO, it is a common fact, that the log server is not reachable at the time the logging application starts. The reconnection connector takes care of this in a "silent" manner. If one was interested in log4j verbosity, use LogLog. setInternalDebugging(true). The same "silent" policy should be applied to the first connection trial initiated by activateOptions() method. My current work around is calling LogLog.setQuietMode(true) before the log4j initialization procedure -- which mutes all other interesting messages as well.
1.2.12 candiate
1.2.15 candidate
Note: In log4j 1.2 branch, there is currently no 'error' level internal logging. To minimize the amount of change, I'm proposing to make this a warn level internal event, and remove the stack trace. I plan to commit the following diff: Index: src/java/org/apache/log4j/net/SocketAppender.java =================================================================== --- src/java/org/apache/log4j/net/SocketAppender.java (revision 531299) +++ src/java/org/apache/log4j/net/SocketAppender.java (working copy) @@ -211,7 +211,7 @@ msg += " We will try again later."; fireConnector(); // fire the connector thread } - LogLog.error(msg, e); + LogLog.warn(msg); } }
If I had been more caffeinated I would have seen there really is a LogLog.error(String) method, which I'm using instead.