10 May
2011
10 May
'11
9:43 a.m.
+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 <
mariusdumitru.florea(a)xwiki.com> wrote:
+1
Thanks,
Marius
On 05/09/2011 02:37 PM, Vincent Massol wrote:
http://www.google.fr/search?aq=f&sourceid=chrome&ie=UTF-8&q=slf…
> * 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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).