[ 
https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479503#comment-16479503
 ] 

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
{code}
log.debug("Foo.bar(param='"+param+"') called");
{code}
as wrongly unparameterised since it should be
{code}
log.debug("Foo.bar(param='{}') called", param);
{code}
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 
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.0/lucene/build.xml#L156-L199
 is for Lucene and 
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.0/solr/build.xml#L678
 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
(v7.6.3#76005)

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

Reply via email to