+1, this should be straight forward with the bridge for legacy code since I have already done so in the past on old version, just by packaging the proper jars (while testing cloud integration, since logback allows logging to database, which is very useful when access to FS is restricted) Thanks, Denis On Tue, May 10, 2011 at 08:04, Marius Dumitru Florea < [email protected]> wrote:
+1
Thanks, Marius
On 05/09/2011 02:37 PM, Vincent Massol wrote:
Hi,
I'd like to propose switching from Commons Logging/Log4j to SLF4J/Logback for the following reasons:
* slf4j was written to solve the issues with commons logging (memory leaks under some circumstances).
http://www.google.fr/search?aq=f&sourceid=chrome&ie=UTF-8&q=slf4j+vs+commons...
* logback is the successor of log4j and addresses the following when
compared to lgog4j:
http://logback.qos.ch/reasonsToSwitch.html
* New stuff happens in logback and not in log4j
* I'd also like to switch to logback since it has full-fledged JMX support which allows us to easily change logging configuration at runtime (changing log levels for example): http://logback.qos.ch/manual/jmxConfig.html
Note that migrating a log4j.properties file is easy: http://logback.qos.ch/translator/
In addition if a user wants to stay on log4j it would be possible and easy: simply remove the logback jar and replace it with the slf4j-log4j one.
WDYT?
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO