[
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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
