Christine Poerschke commented on LUCENE-7788:

Hi [~erickerickson] - thanks for the questions!

bq. 1> WDYT about failing all logging messages that aren't parameterised? Is 
there any reason any logging message should not be parameterised?

Interesting point, would we need to differentiate {{log.debug("Foo.bar() 
called");}} as legitimately(\?) unparameterised from
log.debug("Foo.bar(param='"+param+"') called");
as wrongly unparameterised since it should be
log.debug("Foo.bar(param='{}') called", param);
instead? Or would the expectation be that the first unparameterised logging is 
actually discouraged and instead it should include a parameter e.g. to 
differentiate different {{Foo}} object instances?

bq.2> Let's say we fix up one directory (solr/core for example). Can we turn on 
the precommit check on a per-directory basis?

I like the idea of incrementally changing things and 'locking in' changes made. 
For javadocs 
 is for Lucene and 
 for Solr have such per-directory differentiation, I don't know what it would 
take for other precommit checks to do something similar.

> fail precommit on unparameterised log.trace messages
> ----------------------------------------------------
>                 Key: LUCENE-7788
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7788
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Christine Poerschke
>            Assignee: Christine Poerschke
>            Priority: Minor
>         Attachments: LUCENE-7788.patch, LUCENE-7788.patch
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.

This message was sent by Atlassian JIRA

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

Reply via email to