[ 
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662476#action_12662476
 ] 

Yonik Seeley commented on LUCENE-1482:
--------------------------------------

I'm not arguing for or against SLF4J at this point, but simply pointing out 
that I didn't think it was appropriate to base any analysis on the NOP adapter, 
which can't be used for any project already using SLF4J.

I think using a logger to replace the infostream stuff is probably acceptable.  
What I personally don't want to see happen is instrumentation creep/bloat, 
where debugging statements slowly make their way all throughout Lucene.

bq. Because I seriously don't understand why you think that checking if debug 
is enabled can pose any performance hit, even when used with a real logger.

I've tried to explain - these calls can be costly if used in the wrong place, 
esp on the wrong processor architectures.  What appears in inner loop will vary 
widely by application, and there are a *ton* of lucene users out there using it 
in all sorts of ways we can't imagine.  For example, I'd rather not see 
debugging in Query/Weight/Scorer classes - for most applications, query and 
weight construction won't be a bottleneck, but there are some where it could be 
(running thousands of stored queries against each incoming document via 
memoryindex for example).


> Replace infoSteram by a logging framework (SLF4J)
> -------------------------------------------------
>
>                 Key: LUCENE-1482
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1482
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Shai Erera
>             Fix For: 2.4.1, 2.9
>
>         Attachments: LUCENE-1482-2.patch, LUCENE-1482.patch, 
> slf4j-api-1.5.6.jar, slf4j-nop-1.5.6.jar
>
>
> Lucene makes use of infoStream to output messages in its indexing code only. 
> For debugging purposes, when the search application is run on the customer 
> side, getting messages from other code flows, like search, query parsing, 
> analysis etc can be extremely useful.
> There are two main problems with infoStream today:
> 1. It is owned by IndexWriter, so if I want to add logging capabilities to 
> other classes I need to either expose an API or propagate infoStream to all 
> classes (see for example DocumentsWriter, which receives its infoStream 
> instance from IndexWriter).
> 2. I can either turn debugging on or off, for the entire code.
> Introducing a logging framework can allow each class to control its logging 
> independently, and more importantly, allows the application to turn on 
> logging for only specific areas in the code (i.e., org.apache.lucene.index.*).
> I've investigated SLF4J (stands for Simple Logging Facade for Java) which is, 
> as it names states, a facade over different logging frameworks. As such, you 
> can include the slf4j.jar in your application, and it recognizes at deploy 
> time what is the actual logging framework you'd like to use. SLF4J comes with 
> several adapters for Java logging, Log4j and others. If you know your 
> application uses Java logging, simply drop slf4j.jar and slf4j-jdk14.jar in 
> your classpath, and your logging statements will use Java logging underneath 
> the covers.
> This makes the logging code very simple. For a class A the logger will be 
> instantiated like this:
> public class A {
>   private static final logger = LoggerFactory.getLogger(A.class);
> }
> And will later be used like this:
> public class A {
>   private static final logger = LoggerFactory.getLogger(A.class);
>   public void foo() {
>     if (logger.isDebugEnabled()) {
>       logger.debug("message");
>     }
>   }
> }
> That's all !
> Checking for isDebugEnabled is very quick, at least using the JDK14 adapter 
> (but I assume it's fast also over other logging frameworks).
> The important thing is, every class controls its own logger. Not all classes 
> have to output logging messages, and we can improve Lucene's logging 
> gradually, w/o changing the API, by adding more logging messages to 
> interesting classes.
> I will submit a patch shortly

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to