[xwiki-devs] [Proposal] Switch from Commons Logging/Log4j to SLF4J/Logback
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
I forgot to also mention this page which explains how to have all external fwks log to SLF4J: http://www.slf4j.org/legacy.html Thanks -Vincent On May 9, 2011, at 1: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
+1 On Mon, May 9, 2011 at 13:37, Vincent Massol <[email protected]> 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
-- Thomas Mortagne
On 05/09/2011 01: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?
+1. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Also note that this doesn't change our component code since they use our Logging Facade and are thus isolated. Thanks -Vincent On May 9, 2011, at 1: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
+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
+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
There's one issue with slf4j to be aware of. As you probably know slf4j does not allow several versions of slf4j (APIs and implementations) to be located in the classpath. This applies for e.g. JBoss 5.1. It internally uses older version of slf4j. By default in JBoss 5.1 applications do not have isolated classpath. This results in JBoss slf4j being loaded first and potentially conflicting with your app's slf4j may you try to deploy (especially for newer versions of slf4j). This may not be a critical issue (in our case things worked, but we've isolated our web application's classpath and yet the warning got printed), but worth double-checking. Check this post for the details of the issue http://community.jboss.org/thread/157454 Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Switch-from-Commons-Logging-Log4j... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Wed, May 11, 2011 at 17:46, coldserenity <[email protected]> wrote:
There's one issue with slf4j to be aware of. As you probably know slf4j does not allow several versions of slf4j (APIs and implementations) to be located in the classpath. This applies for e.g. JBoss 5.1. It internally uses older version of slf4j. By default in JBoss 5.1 applications do not have isolated classpath. This results in JBoss slf4j being loaded first and potentially conflicting with your app's slf4j may you try to deploy (especially for newer versions of slf4j).
This may not be a critical issue (in our case things worked, but we've isolated our web application's classpath and yet the warning got printed), but worth double-checking.
Check this post for the details of the issue http://community.jboss.org/thread/157454
Anyway in this case all you have to do is remove from xwiki so that it use the one provided by JBoss which make sense anyway.
Regards, Roman
-- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Switch-from-Commons-Logging-Log4j... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
Anyway in this case all you have to do is remove from xwiki so that it use the one provided by JBoss which make sense anyway.
Agree. Unless slf4j API used in XWiki is new enough to be incompatible with the one in JBoss 5.1 (implementation for which, by the way, is a custom one - it contains 2 additional JBoss classes with unknown purpose and removal impact). I guess it's rather the issue with JBoss (which is promised to be fixed in either v6 or v7). Just something to be aware of. ( Sorry for disturbing the vote process :) ) -- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Switch-from-Commons-Logging-Log4j... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On May 11, 2011, at 6:10 PM, coldserenity wrote:
Thomas Mortagne wrote:
Anyway in this case all you have to do is remove from xwiki so that it use the one provided by JBoss which make sense anyway.
Agree. Unless slf4j API used in XWiki is new enough to be incompatible with the one in JBoss 5.1 (implementation for which, by the way, is a custom one - it contains 2 additional JBoss classes with unknown purpose and removal impact).
I guess it's rather the issue with JBoss (which is promised to be fixed in either v6 or v7). Just something to be aware of. ( Sorry for disturbing the vote process :) )
No, no, thanks a lot for bringing this to the table. I don't think we should change our mind based on this but it's good to know and we'll need to update the JBoss install page with this information. Thanks -Vincent
participants (6)
-
coldserenity -
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol