[Call Summary] Community Call - 4th June 2026
0 views
Skip to first unread message
Robert Young
Jun 3, 2026, 4:56:46 PM (4 days ago) Jun 3
to kroxylic...@googlegroups.com
Hi all!
Today we solely discussed our plans to move the Kafka RPC classes (and associated internal classes like MemoryRecords) under kroxylicious packaging.
Today we solely discussed our plans to move the Kafka RPC classes (and associated internal classes like MemoryRecords) under kroxylicious packaging.
Currently our Filter plugin APIs are tied to the kafka-clients module, and classes like MemoryRecords have recently been moved to a clearly internal package in 4.3.0, which means breaking changes for Filter Authors. Looking forward to 1.0.0 it is unappealing to declare we have a stable plugin API with this dependency, so Peter Płaczek has been investigating different approaches to establishing equivalent classes under our namespace. We discussed these approaches and came up with a plan.
We decided:
1. fork the internal (MemoryRecords etc) classes directly into a kroxylicious package.
2. fork the upstream apache kafka MessageGenerator to produce equivalent RPC classes.
This will be part of the 1.0.0 release (the other requirements for 1.0.0 are still under discussion) as we don't see a neat path to gradually introduce this. There will be accompanying heavy testing of mutual interoperability between kafka-clients and our forked classes.
1. fork the internal (MemoryRecords etc) classes directly into a kroxylicious package.
2. fork the upstream apache kafka MessageGenerator to produce equivalent RPC classes.
This will be part of the 1.0.0 release (the other requirements for 1.0.0 are still under discussion) as we don't see a neat path to gradually introduce this. There will be accompanying heavy testing of mutual interoperability between kafka-clients and our forked classes.
Reply all
Reply to author
Forward
0 new messages