Extending KStream DSL in applications

[Mathieu Fenniak <ma...@replicon.com>]

Hello devs,

I'd like to be able to create my own KTableProcessorSupplier implementation
in a Kafka Streams application, but it's currently not possible without the
use of reflection due to KTableImpl's valueGetterSupplier
& enableSendingOldValues methods being package-local.

Would there be any opposition to a PR to make these methods public?

I do understand that implementing interfaces & using classes in an
"internals" package are obviously going to be an unstable API.  But my
current alternative is to swap from DSL to low-level API via a topic, and
then swap back, when I can't do something directly with the existing API...
and that makes my extensions quite divergent from anything I could feasibly
contribute back to the library in the future. :-)

Thanks,

Mathieu

Re: Extending KStream DSL in applications

["Matthias J. Sax" <ma...@confluent.io>]

Hi,

personally, I do not see a good reason to change it. I guess, the
simplest thing for you to do is, to patch the code in a private repo and
build the library by yourself.

That's the beauty of open source :)


-Matthias


On 12/3/16 8:44 PM, Mathieu Fenniak wrote:
> Hello devs,
> 
> I'd like to be able to create my own KTableProcessorSupplier implementation
> in a Kafka Streams application, but it's currently not possible without the
> use of reflection due to KTableImpl's valueGetterSupplier
> & enableSendingOldValues methods being package-local.
> 
> Would there be any opposition to a PR to make these methods public?
> 
> I do understand that implementing interfaces & using classes in an
> "internals" package are obviously going to be an unstable API.  But my
> current alternative is to swap from DSL to low-level API via a topic, and
> then swap back, when I can't do something directly with the existing API...
> and that makes my extensions quite divergent from anything I could feasibly
> contribute back to the library in the future. :-)
> 
> Thanks,
> 
> Mathieu
>