[ 
https://issues.apache.org/jira/browse/KAFKA-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16108984#comment-16108984
 ] 

Paolo Patierno commented on KAFKA-5684:
---------------------------------------

This JIRA won't change the API. It's just a different way to implement the 
print processor on top of peek processor but all the external stuff will remain 
the same.
The question (on dev list) related to why print() is not fluent does need a KIP 
but I'd like to know the reason why from fluent it was changed to be no fluent. 
I think that people who made this change thought about that for a good reason.

> KStreamPrintProcessor as customized KStreamPeekProcessor
> --------------------------------------------------------
>
>                 Key: KAFKA-5684
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5684
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Paolo Patierno
>            Assignee: Paolo Patierno
>            Priority: Minor
>              Labels: needs-kip
>
> Hi,
> the {{KStreamPrintProcessor}} is implemented from scratch (from the 
> {{AbstractProcessor}}) and the same for the related supplier.
> It looks to me that it's just a special {{KStreamPeekProcessor}} with 
> forwardDownStream to false and that allows the possibility to specify Serdes 
> instances used if key/values are bytes.
> At same time used by a {{print()}} method it provides a fast way to print 
> data flowing through the pipeline (while using just {{peek()}} you need to 
> write the code).
> I think that it could be useful to refactoring the {{KStreamPrintProcessor}} 
> as derived from the {{KStreamPeekProcessor}} customizing its behavior.
> Thanks,
> Paolo.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to