[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-1482:
-------------------------------
Attachment: LUCENE-1482.patch
This patch covers:
- Using SLF4J in all the classes that used infoStream
- A test which uses the JDK14 adapter to make sure it works, as well as fixing
few tests which relied on some messages
- Deprecation of setInfoStream(), getInfoStream() etc. in several classes who
exposed this API.
Few notes:
- As in many customer environments I know of the INFO level is usually turned
on, and we were forbidden to output any message in the INFO level, unless it's
really INFO, WARNING or SEVERE, I assumed Lucene logging messages should be in
the DEBUG level (which is one less than TRACE).
- I wasn't sure what to do with the set/get infoStream methods, so I just
deprecated them and do nothing (i.e., setInfoStream does nothing and
getInfoStream always returns a null).
Not sure how's that align with Lucene's back-compat policy, but on the other
hand I didn't think I should keep both infoStream and SLF4J logging in the code.
- Should I attach the slf4j jars separately?
- I didn't go as far as measuring performance because:
1. The code uses isDebugEnabled everywhere, which is at least judging by the
JDK14 adapter very fast (just checks a member on the actual logger instance)
and is almost equivalent to infoStream != null check.
2. It really depends on the adapter that's being used. I used JDK14, but
perhaps some other adapter will perform worse on these calls, although I expect
these calls to be executed quickly, if not even being inlined by the compiler.
> 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
> Priority: Minor
> Fix For: 2.4.1, 2.9
>
> Attachments: LUCENE-1482.patch
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
