[
https://issues.apache.org/jira/browse/SOLR-12301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-12301.
-----------------------------------
Fix Version/s: 8.6
Resolution: Fixed
This will be slightly untidy for the rest of Solr 8x. LUCENE-7788 fixed all the
logging calls in both master and 8.6 as per this JIRA.
However, only the master gradle "check" and "precommit" actions have checks
that will flag these kinds of problems and fail, so in the interim some of
these may creep back into future 8x releases. This shouldn't be much of a
problem for any code that has gradle check or precommit run before merging into
8x.
Back-porting to Ant is more trouble that this issue is worth given 8x has been
cleaned up.
> Umbrella issue: paramaterize logging calls in Solr, use consistent naming
> conventions for the logger
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-12301
> URL: https://issues.apache.org/jira/browse/SOLR-12301
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
> Fix For: 8.6
>
>
> See the discussion at SOLR-12286 for a lot of background, but the short form
> is that logging calls of the form
> log.info("somehting" + "something");
> and
> log.info("soemthing {}", object.someFunction());
> where someFunction includes toString()
> generate useless garbage/work even when the message is not printed.
> log.info("somehting {}", "something");
> and
> log.info("soemthing {}", object);
> do not. The first form is something of a relic, and there are even some uses
> of the second.
> This will entail a LOT of changes, but almost all secretarial. I'll take it
> in chunks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
