[ https://issues.apache.org/jira/browse/SOLR-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434044#comment-17434044 ]
Chris M. Hostetter commented on SOLR-15703: ------------------------------------------- bq. ...I hate SolrException.log()! In particular that it string-ifies the stack trace thus producing a long message... FYI: That behavior was actually fixed in SOLR-15628. At this point the biggest "perk" in replacing all the existing calls to SolrException.log with log.error is to ensure the source-pattern checks for good logging behavior are respected (because they don't look for SolrException.log) > replace all SolrException.log usage in Solr to just call log.error(...) > directly > -------------------------------------------------------------------------------- > > Key: SOLR-15703 > URL: https://issues.apache.org/jira/browse/SOLR-15703 > Project: Solr > Issue Type: Sub-task > Reporter: Chris M. Hostetter > Assignee: Chris M. Hostetter > Priority: Major > > There is a lot of code in Solr that uses {{SolrException.log(log, ..)}} as a > way to ensure that the resulting exception can be "ignored" in tests via > {{SolrException.ignorePatterns}} / {{SolrTestCaseJ4.ignoreException()}} > This "test feature" is being cleaned up / replaced in SOLR-15697 so that > _any_ log message can be "muted" - meaning we don't need this special > hook/hack – we can replace all calls to {{SolrException.log(log, ..)}} with > (more efficient) direct calls to {{log.error(..)}} > But this change isn't trivially to do in a scripted/automated manner – > notably many of these {{SolrException.log(log, ..)}} use string concatenation > that needs to be replaced with logging parameterization to pass our > {{validateLogCalls}} check. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org