[jira] [Commented] (SOLR-15629) replace SolrException.ignorePatterns with a a new test-framework Rule

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

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

Chris M. Hostetter commented on SOLR-15629:
-------------------------------------------

Strawman idea of what this might look like from an API standpoint:
 * new abstract {{FilterOutLogMessagesTestRule}} class included in test-framework
 * deals with managing the lifecycle of a dynamically created {{Filter}} on the root loger
 * includes static helper methods for creating instances of this new Rule using simple input to indicate which log messages should be ignored.
 ** CharSequence for simple substring, vs Pattern for regex, vs Function for fine grain control
 * Filter could use it's own Logger for INFO level summary of what it's ignore
 ** with obvious check to prevent infinite loop
 * Maybe even support options to _expect_ some number of matches against Filter - to allow tests to start asserting that certain WARN/ERROR are logged?
 ** base class can handle counting how many LogEvents it rejects
 ** Some public method (that can be chained) to take in a count (or lambda) to specify/validate the number of matching messages (and fail the test otherwise) once the test is complete

{code:java}
// what the usage might look like...

@Rule public TestRule logMsgSubString1 = FilterOutLogMessagesTestRule.error("ignoreMe");
@Rule public TestRule logMsgSubstring2 = FilterOutLogMessagesTestRule.warn("ignoreMe");

// applies to any log level, only looks at Throwable
@Rule public TestRule throwableMsg = FilterOutLogMessagesTestRule.throwable(Pattern.compile("foo.*bar"));

// super generic...
@Rule public TestRule custom = FilterOutLogMessagesTestRule.custom(logEvent -> {
  return logEvent.getContextData().get("collection").equals("foo")
    && logEvent.getMessage().contains("bar") });

// fail the test if we don't see this many matching messages...
@Rule public TestRule logMsgSubString3 = FilterOutLogMessagesTestRule.error("ignoreMe").expect(5);
@Rule public TestRule logMsgSubstring4 = FilterOutLogMessagesTestRule.warn("ignoreMe").expect(actual -> {
   return actual == this.numTimesWeRandomlyTriggeredBadBeavior });

{code}
(If/when we do this, we could potentially make {{SolrTestCase}} start to fail if *ANY* unexpected ERROR/WARN makes it past the configured filters)

> replace SolrException.ignorePatterns with a a new test-framework Rule 
> ----------------------------------------------------------------------
>
>                 Key: SOLR-15629
>                 URL: https://issues.apache.org/jira/browse/SOLR-15629
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Chris M. Hostetter
>            Priority: Major
>
> We should deprecated & remove the following code:
>  * {{SolrException.log()}}
>  * {{SolrException.ignorePatterns}}
>  * {{SolrTestCaseJ4.ignoreException()}}
>  * {{SolrTestCaseJ4.unIgnoreException()}}
>  * {{SolrTestCaseJ4.resetExceptionIgnores()}}
> ...and replace with something along the lines of ... (from SOLR-15628) ...
> {quote}We should probably re-think the entire existence of {{SolrException.log()}} and the API design of {{SolrException.ignorePatterns}} – replacing all callers of {{SolrException.log()}} with {{logger.error()}} and use a new test-only log4j Filter/Appdener
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org