lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Java logging in Lucene
Date Fri, 05 Dec 2008 19:06:08 GMT

I also feel that the primary usage of the internal messaging in Lucene  
today is debugging, and we don't need a logging framework for that.


Doug Cutting wrote:

> The infoStream stuff goes back to 1997, before there was log4j or any
> other Java logging framework.
> There's never been a big push to add logging to Lucene.  It would  
> add a dependency, and Lucene's jar has always been standalone, which  
> is nice.  Dependencies can conflict.  If Lucene requires one version  
> of a dependency, then it may not work well with code that require a  
> different version of that dependency.
> And it hasn't been clear which framework to adopt.  Log4j is the  
> granddaddy, then there's Java logging and commons logging.  Today  
> the preferred framework is probably SLF4J.  Good thing we didn't  
> choose the wrong one years ago!
> And how many log entries would folks really want to see per query or  
> document indexed?  In production I don't think most folks want to  
> see more than one entry per query or document indexed.  So finer- 
> grained logging would be for debugging.  For that one can instead  
> use a debugger.  Hence the traditional lack of demand for detailed  
> logging in Lucene.
> That's the history as I recall it.  The future is less clear.
> Doug
> Grant Ingersoll wrote:
>> I think the main motivation has always been to have no dependencies  
>> in the core so as to keep it as fast and lightweight as possible.   
>> Then, of course, there is always the usual religious wars around  
>> which logging framework to use, not to mention the nightmare that  
>> is trying to manage multiple logging frameworks across several  
>> projects that are being integrated.  Then, of course, there is the  
>> question of how useful any core Lucene logs would be to users  
>> writing search applications.  For the most part, my experience has  
>> been that I want logging to tell me when a document was added, when  
>> searches occur, etc. but I don't necessarily need to know things  
>> like the fact that Lucene is now entering the analysis phase of  
>> Document inversion.  And, for all these needs, I can just as well  
>> do that logging in the application and not in Lucene.
>> All that is not to say we couldn't add in logging, I'm just  
>> suggesting reasons I can think of for why it has not been added to  
>> date and why I am not sure it needs to be there going forward.  I  
>> believe various other people have contributed reasons in the past.   
>> I seem to recall Doug spelling some out, but don't have the thread  
>> handy.
>> -Grant
>> On Dec 5, 2008, at 1:17 PM, Shai Erera wrote:
>>> Hi
>>> I was wondering why doesn't the Lucene code uses Java logging,  
>>> instead of the infoStream set in IndexWriter? Today, if I want to  
>>> enable tracing of Lucene code, the only thing I can do is set an  
>>> infoStream, but then I get many many messages. Moreoever, those  
>>> messages seem to cover indexing code only.
>>> I hope to get some opinions on the use of Java logging instead of  
>>> infoStream, and hopefully to start addind logging messages in  
>>> other places in the code (like during search, query parsing etc.)
>>> I feel that this is an approach the community has to decide on  
>>> before we start adding messages to the code. Using Java logging  
>>> can greatly benefit tracing of indexing applications who use  
>>> Lucene. If the vote is +1 for using Java logging, we can start by  
>>> deprecating infoStream (in 2.9, remove in 3.0) and use logging  
>>> instead.
>>> What do you think?
>>> Shai
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message