[
https://issues.apache.org/jira/browse/KAFKA-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048626#comment-16048626
]
Bobby Calderwood commented on KAFKA-3455:
-----------------------------------------
Hi Michal Borowiecki,
Sorry for the late reply. I am trying to implement both {{Transformer}} and
{{Processor}} on the same class. For some interesting use-cases in a Clojure
compatibility library for Kafka Streams that I'm writing, I'd like to hook a
single piece of logic into both the high-level (via {{Transformer}}) and
low-level (via {{Processor}}) APIs. However, when implementing both
interfaces, I encounter the following error due to differing signatures of the
respective {{punctuate(long)}} methods:
{code:none}
<redacted>/TransducerProcessor.java
Error:Error:line (44)java: method punctuate(long) is already defined in
class kafka_streams_clojure.TransducerProcessor
Error:Error:line (10)java: kafka_streams_clojure.TransducerProcessor is not
abstract and does not override abstract method punctuate(long) in
org.apache.kafka.streams.kstream.Transformer
Error:Error:line (40)java: punctuate(long) in
kafka_streams_clojure.TransducerProcessor cannot implement punctuate(long) in
org.apache.kafka.streams.kstream.Transformer
return type void is not compatible with java.lang.Object
{code}
I believe you're right about AutoCloseable, it's been a while since I've been
in Java-land :-)
Yes, I believe that once the incompatible punctuate methods are deprecated and
then removed, my issue would be resolved.
> Connect custom processors with the streams DSL
> ----------------------------------------------
>
> Key: KAFKA-3455
> URL: https://issues.apache.org/jira/browse/KAFKA-3455
> Project: Kafka
> Issue Type: Sub-task
> Components: streams
> Affects Versions: 0.10.0.1
> Reporter: Jonathan Bender
> Labels: user-experience
>
> From the kafka users email thread, we discussed the idea of connecting custom
> processors with topologies defined from the Streams DSL (and being able to
> sink data from the processor). Possibly this could involve exposing the
> underlying processor's name in the streams DSL so it can be connected with
> the standard processor API.
> {quote}
> Thanks for the feedback. This is definitely something we wanted to support
> in the Streams DSL.
> One tricky thing, though, is that some operations do not translate to a
> single processor, but a sub-graph of processors (think of a stream-stream
> join, which is translated to actually 5 processors for windowing / state
> queries / merging, each with a different internal name). So how to define
> the API to return the processor name needs some more thinking.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
