SLF4J has the significant advantage that is can adapt easily to any mainline logging convention when Mahout is included as part of some other project. Whether the including project's convention is java.util, commons, log4j or slf4j, the use of slf by us will allow our code to conform to the outer level standard by the simple selection of which slf jar file the outer project includes. This would make it much easier to adopt our software.
I don't think that any other choice will allow that. On Mon, May 12, 2008 at 2:55 PM, Sean Owen (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/MAHOUT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596212#action_12596212] > > Sean Owen commented on MAHOUT-52: > --------------------------------- > > I could not agree more that logging is important. > > I think the blog post echoes my sentiment that a *facade* logging system > probably adds little value in many situations. I'm not sure he was > suggesting JCL itself is a bad choice. He also says what I suspected, that > classloader-related gripes about JCL are not specific to JCL. If it's what > I'm thinking of, yeah, this comes up for log4j or any other such system > where a parent classloader's copy of the classes are used, but, it tries to > load some class known only to the child classloader by reflection -- which > would work fine when on the child classloader exists. > > If all that's right, then that's an equal argument against both JCL and > SLF4J. I'd reopen the debate about whether we should use log4j or > java.util.logging directly then, but I feel like there is some consensus > here around just using what Hadoop uses since this will be tying in tightly > with Hadoop. > > And then that is an arugment for JCL over SLF4J. > > SLF4J *does* have a nice solution for the "if (debug enabled) {...}" > idiom, which is to use a lightweight message format system. I suppose I'd > say it's no less necessary that the developer be cognizant of the > performance issue here; the solution is just different. > > I suppose I am still not sold on using SLF4J but that's now two people > that have voiced some support for it, so I am intrigued. At the moment I > personally still find the "use what Hadoop uses" argument most compelling. > If we introduce SLF4J... consider that then our combined package will use, > count 'em, *four* different logging systems. > > (I really hope Hadoop standardizes here. I wonder if, eh, we can send over > some patches?) > > > Standardize on java.util.logging, Commons Logging, log4j? > > --------------------------------------------------------- > > > > Key: MAHOUT-52 > > URL: https://issues.apache.org/jira/browse/MAHOUT-52 > > Project: Mahout > > Issue Type: Improvement > > Reporter: Sean Owen > > Priority: Minor > > > > I see the log4j and Commons Logging .jars in the lib/ directory. log4j > isn't used; Commons Logging is used in one class (Parametered). My code just > used java.util.logging directly. > > I figure we should standardize on one approach to logging. I personally > think they're all just about the same; the only real best practice is using > one system. > > I have always just used java.util.logging since it is built into Java > 1.4+. Commons Logging offers an extra layer of abstraction and lets you > switch between java.util.logging and log4j underneath. That's cool, but I've > not found it compelling enough to want to add another layer and another .jar > file. > > But, I guess log4j is present because hadoop uses it directly? The .jar > seems to have a dependency on it. > > In that case maybe we are better off using Commons Logging to let us > integrate with log4j logging that Hadoop uses, and leave open the > possibility of other callers using java.util.logging underneath. > > If that's cool I can switch my code to use Commons Logging. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- ted
