You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (Reopened) (JIRA)" <ji...@apache.org> on 2011/12/02 20:59:40 UTC

[jira] [Reopened] (LUCENE-3598) Improve InfoStream class in trunk to be more consistent with logging-frameworks like slf4j/log4j/commons-logging

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

Michael McCandless reopened LUCENE-3598:
----------------------------------------


I noticed a few accidental changes here (lost an important !success);
I fixed those (rev 1209663), but while fixing them I noticed.... we
are inconsistent on when we call infoStream.isEnabled?  Sometimes we
call it, sometimes we don't.

I think we should always call it?  I don't like that there's a sudden
inconsistency (it was consistent before), and that now present &
future coders working on our code must now wonder/think about when to
check and when not to.  I think the rule should be very simple:
always call .isEnabled.

And I don't think we should assume it's "cheap" to always call
infoStream.message (ie, even when it's a single static string); the
logger could somehow be costly, and had implemented isEnabled exactly
for this reason (so that it's "free" to have a costly
message impl, eg maybe sync'd or something).

Once we fix this... then we can easily test for it by having
NullInfoStream validate it's never called when it wasn't enabled.
                
> Improve InfoStream class in trunk to be more consistent with logging-frameworks like slf4j/log4j/commons-logging
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3598
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3598
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>    Affects Versions: 4.0
>            Reporter: Uwe Schindler
>            Assignee: 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|http://lucene.472066.n3.nabble.com/IndexWriter-infoStream-is-final-td3537485.html]: 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org