I don't know specifically why this is removed, however if you want to get the same functionality you can use peek, i.e:
stream.map(...).peek(...).filter(..) You can log the key values out in the peek call. On Tue, 1 Aug 2017 at 11:48 Paolo Patierno <ppatie...@live.com> wrote: > Hi guys, > > > I was thinking about Kafka Streams debug features and why the print() > method overloads didn't return a KStream, in order to have a fluent DSL > construction even during debugging, but just void. > > Then I came across this PR : > > > https://github.com/apache/kafka/pull/1187 > > > May I ask why the form : > > > stream1 = source.map(...).filter(...); > stream1.print(); // this is for debugging, deleted before moving to > productiong > > stream2 = stream1.transform(...); > stream2.print(); // this is for debugging, deleted before moving to > productiong > > was considered better then the fluent one : > > > source.map(...).filter(...) > .print() // this is for debugging, deleted before moving to > productiong > .transform(...) > .print(); // this is for debugging, deleted before moving to > productiong > > > In this first case the user has to break the topology for printing and > after that, when the code works fine, he has to rewrite the code for > avoiding these broken processors having a fluent construction. > > In the second solution, the user has just to remove the print() calls > without touching the other parts of the code. > > I really liked the first solution (it was something I was going to propose > before coming across the PR :-)). > > > Why this preference on the first one ? > > > Thanks > > > > Paolo Patierno > Senior Software Engineer (IoT) @ Red Hat > Microsoft MVP on Windows Embedded & IoT > Microsoft Azure Advisor > > Twitter : @ppatierno<http://twitter.com/ppatierno> > Linkedin : paolopatierno<http://it.linkedin.com/in/paolopatierno> > Blog : DevExperience<http://paolopatierno.wordpress.com/> >
