KAFKA-8410: Migrating stateless operators to new Processor API#10381
KAFKA-8410: Migrating stateless operators to new Processor API#10381vvcephei merged 16 commits intoapache:trunkfrom
Conversation
There was a problem hiding this comment.
Just FYI, @jeqo , during my POC, I tried to fix this right away, and it dragged me into migrating the entire DSL at once. I think we should do what you are doing instead: just migrate the individual processors first, and then come back and drop the unsafe casts in a later PR.
There was a problem hiding this comment.
One minor thing that bugged me about the old PAPI was the AbstractProcessor class. It was widely used in places where it provided no value. I'm worried that we will just perpetuate here.
Since the new API has default implementations for init and close, the only value this new abstract class provides is when the subclass needs the context. In that case, we save them from the boilerplace of saving off the context in a field.
Therefore, I'd like to call this class ContextualProcessor instead of AbstractProcessor. This should make it a little harder to depend on this class unnecessarily.
| public abstract class AbstractProcessor<KIn, VIn, KOut, VOut> implements Processor<KIn, VIn, KOut, VOut> { | |
| public abstract class ContextualProcessor<KIn, VIn, KOut, VOut> implements Processor<KIn, VIn, KOut, VOut> { |
There was a problem hiding this comment.
Really like this suggestion. Thanks @vvcephei!
b9487a7 to
e174691
Compare
|
Looks like the builds failed due to a checkstyle problem. FYI, you can run |
Migrating KStream stateless operators to new Processor API, first. Following PRs will complete migration of KStream stateful operators and KTable.
Testing strategy: Keep the current tests green.
Committer Checklist (excluded from commit message)