Github user mmiklavc commented on a diff in the pull request:
https://github.com/apache/metron/pull/1184#discussion_r223820390
--- Diff:
metron-platform/metron-parsers/src/main/java/org/apache/metron/parsers/interfaces/MessageParser.java
---
@@ -31,23 +35,41 @@
/**
* Take raw data and convert it to a list of messages.
*
- * @param rawMessage
+ * @param rawMessage the raw bytes of the message
* @return If null is returned, this is treated as an empty list.
*/
List<T> parse(byte[] rawMessage);
/**
* Take raw data and convert it to an optional list of messages.
- * @param parseMessage
+ * @param parseMessage the raw bytes of the message
* @return If null is returned, this is treated as an empty list.
*/
default Optional<List<T>> parseOptional(byte[] parseMessage) {
return Optional.ofNullable(parse(parseMessage));
}
+ /**
+ * Take raw data and convert it to messages. Each raw message may
produce multiple messages and therefore
+ * multiple errors. A {@link MessageParserResult} is returned, which
will have both the messages produced
+ * and the errors.
+ * @param parseMessage the raw bytes of the message
+ * @return Optional of {@link MessageParserResult}
+ */
+ default Optional<MessageParserResult<T>> parseOptionalResult(byte[]
parseMessage) {
--- End diff --
I had mixed feelings about this at first. There are 2 levels deep of
Optional, which feels a bit like a code smell. However, our existing interface
has an Optional<List<T>> which is presumably to force a contract to our clients
writing custom parsers, which we have little control over. Contrast this with
the unified enrichment topology where we do control the enrichment process and
so we have no need to deal with Optionals. So I think this interface change is
probably ok.
---
