[
https://issues.apache.org/jira/browse/METRON-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637376#comment-16637376
]
ASF GitHub Bot commented on METRON-1681:
----------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1213
> @mmiklavc Have you looked over this by chance [2]? The reason I bring
this up is because it looks like it already addresses a number of the
points/questions brought up in this PR's discussion. For example, there's a
strategy for handling successful messages as well as error results [3]. If
we're going through the effort of refactoring, it's probably worth our while to
match the other idioms to some degree. It just makes continued maintenance that
much easier going forward.
Are you making the case for returning a `List` here then? Sounds like
you're thinking along these lines?
```
ParserRunner {
List<ParserResult> execute(...);
}
```
That would be similar to the unified enrichment work that you linked to in
your comment.
```
ParallelEnricher {
EnrichmentResult apply(...);
}
```
> Decouple the ParserBolt from the Parse execution logic
> ------------------------------------------------------
>
> Key: METRON-1681
> URL: https://issues.apache.org/jira/browse/METRON-1681
> Project: Metron
> Issue Type: Improvement
> Reporter: Justin Leet
> Priority: Major
>
> Per discussion on https://github.com/apache/metron/pull/1099, there are
> concerns about the ParserBolt needed some refactoring. The discussion didn't
> hold the PR up, but it was generally agreed that we should decouple some of
> the initialization and execution logic.
> This also aids us in integrating with other systems such as NiFi or Spark.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
