notes:

reloading is done by attribute in xml file, so i'm assuming the functionality in initLog4j() is no longer needed

added a duplicate message filter which removes dups after 5

used a standard pattern. folks might want to alter the format. let me know.

logback looks for logback-test.xml first, then logback.xml so specifying loggers for test as -D props not needed.

changed the jmx name to just setLoggingLevel (removing reference to log4j in name)

LGTM, although I was a fan of the old pattern (including briefer output on stdout than the log file).

(Also would need entries for the new jars in lib/licenses of course.)

switch log formats to what the log4j ones where (close anyway)

add/remove licenses

pushed as commit 29605aedd9e19f2f07042cd0aa6b31b6c94a4aea to trunk (2.1)

looks like a few references to log4j were left around. i went thru and tried to clean them all up. attached a diff

remove additional references to log4j

Michael Kjellman I think we'd better have separate setting for server and tools as before, otherwise logback picks up default logback.xml for all tools.

Attaching patch for that.

Yuki Morishita funny, after i attached the patch i was thinking something similar to what you did was better. I'm also thinking that maybe the ccm patch i did to fix 2.1 should use logback-test.xml, but not sure if we want to get that tied into the logback mentality..

Has log4j2 been considered?
Both log4j (old) and logback has awful java code in its internals using synchronised blocks/methods.

log4j2 seems to take a large step forward here and ensures an application won't lock up in the same way a log4j/logback application can. Such contention locks are not unusual once you increase logging in any high concurrent application.

log4j2 can be more than 1000x times faster…
http://logging.apache.org/log4j/2.x/manual/async.html#Performance

We don't log that much so speed is kind of a non-issue for me. Does log4j2 buy us anything else? I'm definitely a fan of logback's auto-reload of config.

No, most people don't log that much. But it's nice to know that you can, if you have to, turn all loggers to DEBUG, or even TRACE, in production without hurting performance. With old-log4j and logback this often isn't possible.

The performance isn't an across the board improvement, as far as i've understood it, but just an improvement that comes from removing all the little contentions from synchronised blocks. I can imagine that this appeals to the c* community, even if it's of little practical meaning for normal production c*

Log4j2 also provides the auto-reload of configuration files. Other features it offers is at http://logging.apache.org/log4j/2.x/

The message pattern used in default logback.xml is not optimal. '%F' and '%L' conversion words should be avoided because "generating the file (or line) information is not particularly fast" (see http://logback.qos.ch/manual/layouts.html).

Romain Ramanantsiarovana, please open an Improvement JIRA bug report with that info - some before/after performance numbers with some defined workload might be interesting.