I mean I'm sure up for it, if now three people are saying this is a good option. I'm halfway through porting my code to JCL, so, let's take a decision. :)
Shall we vote just to move forward here? I split my vote 0.5 for JCL and 0.5 for SLF4J, given the discussion to date. On Mon, May 12, 2008 at 6:05 PM, Ted Dunning <[EMAIL PROTECTED]> wrote: > 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 >
