[
https://issues.apache.org/jira/browse/SOLR-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-15807:
--------------------------------------
Attachment: SOLR-15807-1.patch
Status: Open (was: Open)
I was confused by your comment, but then i went back and looked at my last
comment and realized that the way i wrote it implies the exact opposite of what
i was trying to say – sorry about that...
* I personally think that the "i want to assert things about what log messages
are produced by this little chunk of code i'm going to wrap" is the most
important use case to support – when i said "i want to support it", i ment that
my main goal was supporting this use case, because i think it's the most
convenient way to use something like this given how "chatty" Solr logging can
be.
** I prefer this "try-with-resources" approach to wrapping some code when you
expect to produce an ERROR/WARN over the idea of setting up a test rule for the
same reasons i think {{expectThrows()}} is incredibly useful in many ways that
{{ExpectException}} can be painful to use.
* As long as we have functionality (like what i've already written) that can
wrap arbitrary code – then it will be easy to also use that functionality in a
TestRule
** But if we start by designing for a TestRule, then the same code may not be
easy to use in other ways (like wrapping small snippets of logic)
* _eventually_ it would be nice if we have ...
{quote}... a {{@ClassRule}} on {{SolrTestCase}} that fails the test if there
was *ANY* ERROR or WARN that wasn't "expected" ...
{quote}
** ...but I think it's going to be a while before our logging is ... "calm
enough" ... to enable that by default.
...But if it helps, I will try to create a sibling Sub-Task (w/patch) ASAP
showing what I had in mind for making TestRules out of this logic (or
ErrorLogMuter) so you can see what i was thinking.
----
Independent of Smiley's comments...
I've updated the patch to change {{LogInterceptor}} -> {{LogListener}}
(Interceptor made sense in the parent task when i was assuming one all
encompassing "thing" that would handle listing and muting at the same time but
it doesn't now based on how this code actually works) and resolving all of the
nocommits.
I'm pretty happy with the way this all looks ... but the one hitch is that it
doesn't pass precommit because {{ecjLintMain}} doesn't seem to think
{{AtomicReference.compareAndSet(V, V)}} exists – even though the code compiles
and runs just fine...
{noformat}
> Task :solr:test-framework:ecjLintMain FAILED
----------
1. ERROR in
/home/hossman/lucene/solr/solr/test-framework/src/java/org/apache/solr/util/LogListener.java
(at line 300)
if ( ! this.filter.predicate.compareAndSet((Predicate<String>)null,
predicate) ) {
^^^^^^^^^^^^^^
The method compareAndSet(Predicate<String>, Predicate<String>) is undefined
for the type AtomicReference<Predicate<String>>
----------
1 problem (1 error)
{noformat}
...i'm guessing this is some ECJ bug that I'll have to work around by
refactoring the code a bit – but I haven't dug into it yet.
> Add a "LogInterceptor" helpe class that makes it easy to inspect & assert
> expected log messages
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-15807
> URL: https://issues.apache.org/jira/browse/SOLR-15807
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15807-1.patch, SOLR-15807.patch
>
>
> Following on some of the ideas started/outlined in the parent task...
> we should have an easy way for a block of test code to "intercept" and make
> assertions about log messages from specific loggers (at specific log levels,
> matching specific substrings/regexes) that happen as a result of some actions
> during the test code.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
