> One issue I also noted is that some of the existing Decoder implementations (StringDecoder for example) can accept configurations but currently DumpLogSegments does not provide a way to pass any configurations, it creates an empty VerifiableProperties object each time it instantiates a Decoder instance. If we were to use Deserializer we would also need a way to provide configurations.
BTW, if the known bug gets fixed, we have to make new interface extend `configurable`. Or we can just ignore the known issue as `DumpLogSegments` has no options to take custom configs for `Decoder`. That allow the `Decoder` more simple Chia-Ping Tsai <chia7...@gmail.com> 於 2024年5月22日 週三 下午10:58寫道： > > Thanks for Mickael response! > > >I'm wondering whether we need to introduce a new Decoder interface and > instead if we could reuse Deserializer. We could deprecate the > key-decoder-class and value-decoder-class flags and introduce new > flags like key-deserializer-class and value-deserializer-class. One > benefit is that we already have many existing deserializer > implementations. WDYT? > > I prefer to use different interface, since using the same interface > (Deserializer) may obstruct us from enhancing the interface used by > DumpLogSegments only in the future. > > > One issue I also noted is that some of the existing Decoder > implementations (StringDecoder for example) can accept configurations > but currently DumpLogSegments does not provide a way to pass any > configurations, it creates an empty VerifiableProperties object each > time it instantiates a Decoder instance. If we were to use > Deserializer we would also need a way to provide configurations. > > yep, that is a known issue: > https://issues.apache.org/jira/browse/KAFKA-12311 > > We will file PR to fix it > > Mickael Maison <mickael.mai...@gmail.com> 於 2024年5月22日 週三 下午10:51寫道： > >> Hi, >> >> Thanks for the KIP. Sorting this out in 3.8.0 would be really nice as >> it would allow us to migrate this tool in 4.0.0. We're unfortunately >> past the KIP deadline but maybe this is small enough to have an >> exception. >> >> I'm wondering whether we need to introduce a new Decoder interface and >> instead if we could reuse Deserializer. We could deprecate the >> key-decoder-class and value-decoder-class flags and introduce new >> flags like key-deserializer-class and value-deserializer-class. One >> benefit is that we already have many existing deserializer >> implementations. WDYT? >> >> One issue I also noted is that some of the existing Decoder >> implementations (StringDecoder for example) can accept configurations >> but currently DumpLogSegments does not provide a way to pass any >> configurations, it creates an empty VerifiableProperties object each >> time it instantiates a Decoder instance. If we were to use >> Deserializer we would also need a way to provide configurations. >> >> Thanks, >> Mickael >> >> On Wed, May 22, 2024 at 4:12 PM Chia-Ping Tsai <chia7...@apache.org> >> wrote: >> > >> > Dear all, >> > >> > We know that 3.8.0 KIP is already frozen, but this is a small KIP and >> we need to ship it to 3.8.0 so as to remove the deprecated scala interface >> from 4.0. >> > >> > Best, >> > Chia-Ping >> > >> > On 2024/05/22 14:05:16 Frank Yang wrote: >> > > Hi team, >> > > >> > > Chia-Ping Tsai and I would like to propose KIP-1047 to migrate >> kafka.serializer.Decoder from core module (scala) to tools module (java). >> > > >> > > Feedback and comments are welcome. >> > > >> > > KIP-1047: >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1047+Introduce+new+org.apache.kafka.tools.api.Decoder+to+replace+kafka.serializer.Decoder >> > > JIRA: https://issues.apache.org/jira/browse/KAFKA-16796 >> > > >> > > Thank you. >> > > PoAn >> >
