[
https://issues.apache.org/jira/browse/METRON-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937222#comment-15937222
]
ASF GitHub Bot commented on METRON-793:
---------------------------------------
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/486
@justinleet good points overall. Yeah, I'm not thrilled with the HDP
dependency either, as I stated already.
Regarding "If flux gets support for the Builder items, would we just axe
those classes entirely?"
I believe that the extension will live on. It has a couple of benefits
beyond the builder pattern in flux:
* The parsers aren't using flux and do need a way to expose the
configuration of the spout via properties. This is part of the extension here.
* A component of extension in the storm-kafka-client Builder is via
polymorphism (e.g. the TupleBuilder, etc). This will just never work well in
flux, I think.
* There is an assumption in the storm-kafka-client builder that we're
passing in brokers directly, rather than reading them from zookeeper.
* This API is shifting dramatically. It's totally different in storm 1.0.3
vs 1.0.1. Creating a layer here insulates us from API changes and localizes
their impact.
I made the TODOs because, while what we have here matched the capabilities
of what we had before, we could do better in supporting multiple topics. I
wanted to bring out the places that would need to shift to support that.
> Migrate to storm-kafka-client kafka spout from storm-kafka
> ----------------------------------------------------------
>
> Key: METRON-793
> URL: https://issues.apache.org/jira/browse/METRON-793
> Project: Metron
> Issue Type: Improvement
> Reporter: Casey Stella
>
> In order to eventually support kerberos, the suggested path is to migrate to
> the new kafka spout (org.apache.storm:storm-kafka-client) which uses the new
> consumer API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
