Github user mattf-horton commented on the issue:
https://github.com/apache/incubator-metron/pull/395
@nickwallen and @cestella, I'm fine with this conclusion, but from a design
perspective, the ZkConfigurationManager effort should not be viewed as bringing
the current file to parity with ConfiguredBolt. Rather, the starting point
should be a refactoring of ConfiguredBolt. ConfiguredBolt is only 60 lines of
code that does this thing quite well, with real-time event capture. You want
to add caching of the deserialized configs as well as the raw ZK info, and
that's good. But that can be added on, it is not clear why starting from
scratch is required. Clearly deriving from ConfiguredBolt will also make it
way easier to code review and give confidence in the refactoring.
If you feel it is really necessary to start from scratch, please do a brief
design document stating why. Thanks.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
