I thought the main point is to avoid a jar dependency. If we were to depend on a jar for logging, then why not log4j or commons-logging?
-John On Fri, Dec 5, 2008 at 1:00 PM, Doug Cutting <[EMAIL PROTECTED]> wrote: > Shai Erera wrote: > >> Perhaps instead of introducing Java logging then (if you're too against >> it), we could introdue a static InfoStream class, with a static message() >> and isVerbose() methods. >> > > It's tempting to add our own logging API, as you suggest, but I fear that > would re-invent what so many have re-invented before. > > As for the logging framework, I'd think that Java logging creates no >> dependencies for Lucene. java.util.logging exists at least since 1.4. >> So it's already in the JDK. >> > > Good point. Java's built-in logging would not add a dependency, but it can > still conflict. But in other projects with serious logging needs where I've > tried using Java's built in logging, but we've always ended up switching to > log4j. So I worry that choosing Java's logging might not help those who > need logging, and it would conflict with those who already use log4j. > > You might argue that some applications >> who embed a search component over Lucene use a different logging >> system (such as Log4j), but in that case I think it'd be fair to say >> that Java logging is what Lucene uses. >> > > What do we tell folks who currently use both log4j and Lucene? How would > they benefit from this? > > A meta-logger like SLF4J seems preferable, since it could integrate with > whatever logging system folks already use. Adding this would be an > incompatible change, since folks would need to add new jars into their > applications besides the lucene jar. But that's perhaps not a huge burden. > What do others think? > > Doug > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
