metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (METRON-1681) Decouple the ParserBolt from the Parse execution logic
Date Wed, 03 Oct 2018 18:50:00 GMT


ASF GitHub Bot commented on METRON-1681:

Github user nickwallen commented on the issue:
    > @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:
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Justin Leet
>            Priority: Major
> Per discussion on, 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

View raw message