lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1482) Replace infoSteram by a logging framework (SLF4J)
Date Tue, 23 Mar 2010 06:36:27 GMT

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

Shai Erera commented on LUCENE-1482:
------------------------------------

Well ... since Mark hasn't closed it yet (thanks Mark :)), I thought to try once more. Perhaps
w/ the merge of Lucene/Solr this will look more reasonable now? I personally feel that just
setting InfoStream on IW is not enough. I don't think we need to control logging per level
either. I think it's important to introduce this in at least one of the following modes:
# We add SLF4J and allow the application to control logging per package(s), but the logging
level won't matter - as long as it's not OFF, we log.
# We add a static factory LuceneLogger or something, which turns logging on/off, in which
case all components/packages either log or not.

I think (1) gives us greater flexibility (us as in the apps developers), but (2) is also acceptable.
As long as we can introduce logging messages from more components w/o passing infoStream around
... On LUCENE-2339 for example, a closeSafely method was added which suppresses IOExceptions
that may be caused by io.close(). You cannot print the stacktrace because that would be unacceptable
w/ products that are not allowed to print anything unless logging has been enabled, but on
the other hand suppressing the exception is not good either ... in this case, a LuceneLogger
could have helped because you could print the stacktrace if logging was enabled.

> 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: 3.1
>
>         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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message