[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662039#action_12662039
]
Shai Erera commented on LUCENE-1482:
------------------------------------
Grant, given what I wrote below, having Lucene use NOP adapter, are you still
worried w.r.t. the performance implications?
If there is a general reluctance to add a dependency on SLF4J, can we review
the other options I suggested - using infoStream as a class with static
methods? That at least will allow adding more prints from other classes, w/o
changing their API.
I prefer SLF4J because IMO logging is important, but having infoStream as a
service class is better than what exists today (and I don't believe someone can
argue that calling a static method has any significant, if at all, performance
implications).
If the committers want to drop that issue, please let me know and I'll close
it. I don't like to nag :-)
> 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
