FAQ
[ https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Miller updated LUCENE-1482:
--------------------------------

Fix Version/s: (was: 2.9)
3.0

I'm going to go out on a limb and say this one is too contentious to make 2.9.

If you strongly disagree, please do feel free to flip it back.
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.0

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

Search Discussions

  • Shai Erera (JIRA) at Jun 11, 2009 at 7:23 am
    [ https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718327#action_12718327 ]

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

    I'm not even sure if this issue should be kept around, given the responses I got to it. The question is - do we think logging should be improved in Lucene or not? If YES, then let's keep the issue around and come back in 3.0. If NO, then let's cancel it. It hasn't been commented on for ~6 months, so there's no point to keep it around unless we think it should be resolved at some point
    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.0

    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
  • Mark Miller (JIRA) at Jun 11, 2009 at 10:23 am
    [ https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Mark Miller updated LUCENE-1482:
    --------------------------------

    Fix Version/s: (was: 3.0)
    3.1
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-dev @
categorieslucene
postedJun 11, '09 at 12:35a
activeJun 11, '09 at 10:23a
posts3
users1
websitelucene.apache.org

1 user in discussion

Mark Miller (JIRA): 3 posts

People

Translate

site design / logo © 2021 Grokbase