Doug, bq. 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.
Haven't we already added our own logging API by introducing infoStream in IndexWriter? All I'm proposing (as an alternative to Java logging) is to make it a service for all of Lucene classes, even contrib. I didn't propose to add Java logging-like capabilities, like levels (eventhough I think it's useful), but instead take what IW has today (a message() method) and make a static one for other classes. bq. What do we tell folks who currently use both log4j and Lucene? How would they benefit from this? I don't think it's such a big deal. To turn on Lucene logging, they have to introduce some API (or UI) for users/administrators to configure. They then probably set infoStream to the stream log4j uses. By using Java logging, all we'll ask them is to configure the Java logging system, which is pretty easy. About SLF4J, I'm not familiar with it so I cannot comment. The only thing I can comment about is the additional jar people would have to add to their applications. That's really not an issue imo because people already add many jars to support Lucene. If one uses any contrib package, it's an additional jar. If one wants to use Snowball, it's 2 jars (the snowball and the contrib analyzer). When you use Apache HttpClient, you have to add several jars, which is ok ... Grant, What do you have against JUL? I've used it and in my company (which is quite a large one btw) we've moved to JUL just because it's so easy to configure, comes already with the JDK and very intuitive. Perhaps it has some shortcomings which I'm not aware of, and I hope you can point me at them. The argument on whether to choose JUL, commons, log4j or slf4j can go on, I don't mind participating in it as I think it's interesting. But the core question is whether the community (and especially the committers) think that we need more logging in Lucene, except IW's infoStream. If so, we can start by introducing that InfoStream service class, which willl only expose today's functionality at start (i.e., only indexing code will use), but will allow for other classes to log operations as well. I personally would like to use more standard logging frameworks (and preferrably JUL), but what I want more is the ability to debug my product after it has been shipped. So eventhough it's not as great as standard logging, the InfoStream service is still better than what Lucene has today. My 2 cents. Shai On Sat, Dec 6, 2008 at 12:32 AM, Jason Rutherglen < [EMAIL PROTECTED]> wrote: > As a developer who would like to eventually develop core code in Lucene (I > started but then things changed drastically and so will wait for flexible > indexing and other APIs?), a standard logging system would make development > easier by making debugging easier. I rely heavily on log analysis in > developing and debugging search code. A detailed view of what is happening > internally will speed development, and as Shai mentioned allow production > and pre-production systems to be monitored in new ways. > > -J > > > On Fri, Dec 5, 2008 at 1:19 PM, Doug Cutting <[EMAIL PROTECTED]> wrote: > >> John Wang wrote: >> >>> If we were to depend on a jar for logging, then why not log4j or >>> commons-logging? >>> >> >> Lucene is used by many applications. Many of those applications already >> perform some kind of logging. We'd like whatever Lucene adds to fit in with >> their existing logging framework, not conflict with it. Thus the motivation >> to use a meta-logging framwork like commons logging or slf4j. And articles >> like the following point towards slf4j, not commons logging. >> >> http://www.qos.ch/logging/thinkAgain.jsp >> >> >> Doug >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >
