[ 
https://issues.apache.org/jira/browse/METRON-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647162#comment-16647162
 ] 

ASF GitHub Bot commented on METRON-1681:
----------------------------------------

Github user merrimanr commented on the issue:

    https://github.com/apache/metron/pull/1213
  
    The latest commit resolves the conflicts introduced by 
https://github.com/apache/metron/pull/1184.  The changes in all classes except 
ParserRunnerImpl and ParserRunnerImplTest were fairly trivial, mainly just 
adjusting the return types to match the new MessageParserResult and 
ParserRunnerResults interfaces.
    
    Most of the work was done in ParserRunnerImpl (the execute method 
specifically).  Since the MessageParser interface can now return multiple 
messages and exceptions (and a master exception in some cases), there needs to 
be a way to map them to a ParserRunnerResults object (which is a list of 
messages and errors).   Now the primary job of this execute method is to:
    - call MessageParser.parseOptionalResult
    - post process messages returned by the MessageParser
    - consolidate the various errors and messages into a single 
ParserRunnerResults object
    
    Let me know if anyone thinks this should work differently.  I also added 
more javadocs to the various classes involved, primarily ParserRunnerImpl since 
that's where the magic happens.  This merge was fairly significant so I am 
planning on testing in full dev again.


> 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)

Reply via email to