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]
