[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662448#action_12662448
]
Shai Erera commented on LUCENE-1482:
------------------------------------
Like I wrote before, I believe that if someone will use a *real* logger, it's
most probably because his application already uses such a logger in other
places of the code, not necessarily just the search parts. Therefore, the
performance implications of using a logger is not important, IMO.
For the sake of argument, what if some writes his own adapter, which performs
really bad on isDebugEnabled() (for example) - is that the concern of the
Lucene community?
The way I view it - this patch gives those who want to control Lucene logging,
better control of it. The fact that Lucene ships with the NOP adapter means it
will not be affected by the logger's isDebugEnabled() calls. If you want to
always output the log messages, drop an adapter which always returns true.
I wonder if there is a general reluctance to use SLF4J at all, and that's why
you continue to raise the performance implications. 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.
If performance measurement is what's keeping this patch from being committed,
I'll run one of the indexing algoirhtms w/ and w/o the patch. I'll use the NOP
adapter and the Java logger adapter so we'll have 3 measurements.
However, if performance is not what's blocking that issue, please let me know
now, so I won't spend test cycles for nothing.
And ... I also proposed another alternative, which is not as good as logging
IMO, but still better than what we have today - offer an InfoStream class with
static methods verbose() and message(). It can be used by all Lucene classes,
w/o changing their API and thus allows adding more messages gradually w/o being
concerned w/ API backward compatibility.
I prefer SLF4J, but if the committers are against it, then this one should be
considered also.
Shai
> 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
