Hi Juan Pablo, I don't have a vote here, nor am I advocating for one really. I'm just noting that in three relatively large enterprise environments that I know of recently they are all using Log4j, having discussed (similar to the discussion here) alternatives such as SLF4j. I certainly understand the rationale for SLF4j, especially in a world where there is a requirement for mixed libraries, so I suppose I don't have an alternative in that regard.
A recent large-scale project involved a bespoke approach that sounds similar to your LoggerManager idea, and while that worked find (and fulfilled a requirement of logging messages to different logs depending on context) it did mean that of the thousands of files in the project they all used this bespoke logger rather than a "standard" like Log4j. I found this a rather ugly solution in that the project was locked into this solution and any deficiencies (such as scaleability or bug fixes by an external team focused on logging) weren't really met. In any case, just throwing in my 2c on finding little value in the SLF4j approach, but certainly YMMV. Logging in Java has always been an issue -- too bad log4j hadn't been adopted into the JDK instead of it into Apache, then we'd not really have any need for the facades... too late for that sadly. Ichiro On Tue, Jul 30, 2013 at 10:17 AM, Juan Pablo Santos RodrÃguez < [email protected]> wrote: > 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 <[email protected]> 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) <[email protected]> > >> 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> > >>> > >>> > > >
