MINOR: Improve usage of LogCaptureAppender

[mjsax]

I started a "small" cleanup, and it ended up to become a "big" cleanup...

• limit the usage of LogCaptureAppender to the class under test (if possible)
• ensure that the registered appended is unregistered (via try-with-resource)
• limit the "scope" of creating/unregistering the appended to a minimum
• cleanup all warning of all classes touched
• some code reformatting
• some class renaming

Call for review @vvcephei

[mjsax]

This is an actual change -- in all other processor, we use the "top level class" for the logger and not the Processor class -- changing this for alignment.

[mjsax]

Removed because unused.

[mjsax]

Removed because unused.

[mjsax]

Removed because the parameter is variadic

[mjsax]

This method is only called once and thus its merged into the main test method

[mjsax]

We don't capture any debug logs and thus it's getting removed

[mjsax]

This method is only called once and thus its merged into the main test method

[ijuma]

Did you consider using try with resources?

[vvcephei]

Thanks, @mjsax ! This is awesome. I'm wondering if we can formalize the pattern you've adopted by implementing AutoCloseable in LogCaptureAppender, and making the close method unregister the appender, so we can convert all those try/finally blocks to try-with-resources? Of course, we'd have to move the assertions inside the block, which we have sometimes and not other times, but it doesn't seem like a big deal either way.

[vvcephei]

Seems like this appender could also be scoped to the class that logs the message we want to capture, right?

[mjsax]

Unfortunately not; I tied it and it fails. The issue is, we would want to register the LogCaptureAppender only for KafkaStreams.class but at this point in the test, the corresponding logger does not exist yet: it's only created in the constructor call, that we actually test. Does this make sense?

[vvcephei]

Thanks, @mjsax ! It seems like we should look into the try-with-resources thing, unless you already rejected that option for some reason. I also registered one complaint below.

But I don't want to block on either one, if you really prefer the current code.

Other than those two issues, it's a really nice cleanup. Thanks!

[vvcephei]

Not a huge fan of this particular "clean up". We're trading a tightly defined scope for de-duplicating the trivial line results.add(deserialization). It doesn't seem like a good trade to me.

[mjsax]

I don't feel "strong" about it -- it was an IntelliJ warning/suggestion to "share common code".

[mjsax]

I did not consider using try-with-resource. Great idea!

[mjsax]

Updated this. Call for review.

[vvcephei]

Thanks, @mjsax ; this is awesome!

I just had one question about renaming the test thread. Otherwise, it LGTM!

[vvcephei]

Hmm, this might be surprising. Won't this cause the test executor thread to be called "threadName" from now until the end of the build?

Do you think we could instead get the currentThread's name and use that in the assertions? Or otherwise make the assertions agnostic to the name of the thread?

[mjsax]

Getting the name is much better! Should have done this for the beginning on...

[mjsax]

Java 8 passed.
Java11: kafka.api.ConsumerBounceTest.testRollingBrokerRestartsWithSmallerMaxGroupSizeConfigDisruptsBigGroup
Java14 failed due to #8519 (already merged).

Retest this please.

[mjsax]

Updated this PR. Will merge after Jenkins passe.

[vvcephei]

LGTM! Thanks.

[mjsax]

Java 8: org.apache.kafka.streams.integration.StandbyTaskEOSIntegrationTest.surviveWithOneTaskAsStandby[exactly_once_beta]
Java 11: org.apache.kafka.connect.mirror.MirrorConnectorsIntegrationTest.testReplication
Java 14: org.apache.kafka.streams.integration.StoreQueryIntegrationTest.shouldQuerySpecificActivePartitionStores

Retest this please.

[mjsax]

Java 8 and Java 11 passed.
Java 14: failed with unknown error...