lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3598) Improve InfoStream class in trunk to be more consistent with logging-frameworks like slf4j/log4j/commons-logging
Date Mon, 28 Nov 2011 19:59:40 GMT


Hoss Man commented on LUCENE-3598:

>From a practical usage standpoint, i think it makes a lot more sense to add minor enhancements
to the "infoStream" concept then it would to start using JUL or SLF4J (or any other logging
API) in the core Lucene code.

with infoStream, the default assumption has always been (and with this patch: seems to continue
to be) that you want "fast" production code w/o the overhead of debugging info.  the client
app has to go out of the way to turn on the debugging info from lucene, recognizing that that
may slow things down.

I don't know of any logging API we could use where that default assumption would remain the
status quo -- JUL, JCL, L4J, SLF4J, etc... if we switched to using any of those the burden
would be on client libraries to actively disable messages coming from Lucene either by adding
a logging config file, or by updating their existing logging config file, or adding a NOOP
SLF4J impl, etc... (even JCL defaults to writting to System.err instead of being a NOOP!)

So lets keep simple/common things simple/common/fast -- and people who want to hook into a
logging framework can do that.

Hell: since JUL is guaranteed to be implemented by all JVMs, and since we already have the
Jar for the SLF4J API in the build system for Solr, it would be trivial to offer out of the
box JUL and SLF4J backed implementations of the InfoStream API to make it *really* trivial
for client apps to use them
> Improve InfoStream class in trunk to be more consistent with logging-frameworks like
> ----------------------------------------------------------------------------------------------------------------
>                 Key: LUCENE-3598
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>    Affects Versions: 4.0
>            Reporter: Uwe Schindler
>         Attachments: LUCENE-3598.patch, LUCENE-3598.patch, LUCENE-3598.patch, LUCENE-3598.patch
> Followup on a [thread by Shai Erea on java-dev@lao|]:
I already discussed with Robert about that, that there is one thing missing. Currently the
IW only checks if the infoStream!=null and then passes the message to the method, and that
*may* ignore it. For your requirement it is the case that this is enabled or disabled dynamically.
Unfortunately if the construction of the message is heavy, then this wastes resources.
> I would like to add another method to this class: abstract boolean isEnabled() that can
also be implemented. I would then replace all null checks in IW by this method. The default
config in IW would be changed to use a NoOutputInfoStream that returns false here and ignores
the message.
> A simple logger wrapper for e.g. log4j / slf4j then could look like (ignoring component,
could be enabled):
> {code:java}
> Loger log = YourLoggingFramework.getLogger(IndexWriter.class);
> public void message(String component, String message) {
>   log.debug(component + ": " + message);
> }
> public boolean isEnabled(String component) {
>   return log.isDebugEnabled();
> }
> {code}
> Using this you could enable/disable logging live by e.g. the log4j management console
of your app server by enabling/disabling IndexWriter.class logging.
> The changes are really simple:
> - PrintStreamInfoStream returns true, always, mabye make it dynamically enable/disable
to allow Shai's request
> - infoStream.getDefault() is never null and can never be set to null. Instead the default
is a singleton NoOutputInfoStream that returns false of isEnabled(component).
> - All null checks on infoStream should be replaced by infoStream.isEanbled(component),
this is possible as always != null. There are no slowdowns by this - it's like Collections.emptyList()
instead stupid null checks.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message