Hi Ichiro, we're relying on several 3rd party libraries, each of them relying on several logging frameworks. SLF4J would allow us to consolidate all application-related logging to the same place. It also supports parameterized log messages, which is a nice to have. As the underlying logging framework, Logback is seen as the evolution of log4j (done by the same author + [#1]). On the other hand, log4j 2 looks pretty nice too, seems it's faster and has more features, however it's still in beta, so API may be broken towards 1.0.0.
Regardless we stick to Log4J, switch to SLF4J+Logback, use Log4j2 or whatever, what I was having in mind was: - having a custom facade: o.a.w.log.WLogger (or WikiLogger, name doesn't matter right now). It should have the logging methods we're all used to (debug, info, etc) and would hide the log implementation used throughout the application. I think this should be a must, reasons below. - means to change the log level of a given package at runtime, with no restarts required. Most probably through an JMX MBean (btw logback provides means to do this up to method level) - a LoggerManager to be init'ed from WikiEngine/EntityManager, performing start-up and shutdown tasks related to logging (read jspwiki.property as config file, init'ing and destroying the MBean and maybe some more things) If we isolate the logging framework and later on we decide that the changes weren't good enough, we can revert to log4j again as the underlying logging implementation, without touching mostly every single file from src. Switching to SLF4J + Logback or Log4j2 as the logging framework is something to be done as soon as we have isolated the logging framework. They require more or less the same amount of configuration as Log4J and they provide additional benefits enough to make me think it's worth the effort. Finally, as switching the underlying logging library is a big change, I think we should run a vote here at dev to decide which library to use br, juan pablo [#1]: logback.qos.ch/reasonsToSwitch.html IMO, esp. interesting automatic compression for FileAppender and graceful recovery from I/O errors On Mon, Jul 29, 2013 at 11:48 PM, Glen Mazza <glen.ma...@gmail.com> wrote: > I put that item in because JP had requested it. JP +1'ed Style C/Sun > indentation, which makes you and me happy, so I'll happily give him his > logging preference of choice, as long as it's a competent solution, and it > is, so that's good enough for me. On a team, you have to give and take to > make everyone happy. > > Glen > > > On 07/29/2013 05:08 PM, Ichiro Furusato wrote: > >> I've followed this debate for years now and it's hard to really justify >> (to >> my mind at least) >> not simply going with Log4j. It's all but a standard. I've used the JDK's >> logging facility >> and SLF4J and there simply is no added benefit to a facade API. The only >> real justification >> would be a project where one didn't want to use *any* additional >> libraries. >> As JSPWiki >> is hardly in that category I'd recommend simply including the log4j.jar >> file and being done >> with it. Log4j works fine and pretty much the entire Java community knows >> and uses it. >> Having a facade over it doesn't really provide any benefits and makes log >> configuration >> just a bit more complicated, especially when JSPWiki is being used in a >> mixed logging >> environment. >> >> So I'd be interested in hearing the arguments in favour of SLF4j, i.e., >> what actual gains >> are expected. >> >> Ichiro >> >> >> >> On Mon, Jul 29, 2013 at 4:17 AM, Glen Mazza (JIRA) <j...@apache.org> >> wrote: >> >> Glen Mazza created JSPWIKI-795: >>> ------------------------------**---- >>> >>> Summary: Update logging subsystem in JSPWiki >>> Key: JSPWIKI-795 >>> URL: https://issues.apache.org/** >>> jira/browse/JSPWIKI-795<https://issues.apache.org/jira/browse/JSPWIKI-795> >>> Project: JSPWiki >>> Issue Type: Improvement >>> Reporter: Glen Mazza >>> >>> >>> Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2]. >>> >>> -- >>> This message is automatically generated by JIRA. >>> If you think it was sent incorrectly, please contact your JIRA >>> administrators >>> For more information on JIRA, see: http://www.atlassian.com/** >>> software/jira <http://www.atlassian.com/software/jira> >>> >>> >
