You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by "Matt Foley (JIRA)" <ji...@apache.org> on 2017/01/03 21:52:58 UTC

[jira] [Commented] (METRON-648) GrokWebSphereParserTest and BasicAsaParserTest are not 2017-safe

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

Matt Foley commented on METRON-648:
-----------------------------------

The Asa Parser is set up to use a Clock object (member object 'deviceClock'), as illustrated in BasicAsaParserTest::testShortTimestamp()

GrokWebSphereParser/GrokParser is not.  Do the owners of Grok Parser care whether the fix is done by adding "2016" to the testString values (easy), vs making GrokParser use a Clock object (more involved)?

> GrokWebSphereParserTest and BasicAsaParserTest are not 2017-safe
> ----------------------------------------------------------------
>
>                 Key: METRON-648
>                 URL: https://issues.apache.org/jira/browse/METRON-648
>             Project: Metron
>          Issue Type: Bug
>    Affects Versions: 0.3.0
>         Environment: Travis operating on branch master
>            Reporter: Matt Foley
>
> In metron-platform/metron-parsers/src/test/java/org/apache/metron/parsers/websphere/GrokWebSphereParserTest.java eight of the test cases use a testString with log contents including a timestamp of "Apr 15" without year specified, then do an assertEquals() comparison against a hardwired epoch value that assumes a "Apr 15 2016" interpretation.
> Unfortunately, now that local time is 2017, it is interpreting these logs as "Apr 15 2017", even though that is in the future from now (Jan 3 as of this writing).  This causes Travis failures without other cause.
> BTW, the assertEquals() calls incorrectly give arguments in order (actual, expected) instead of the correct order (expected, actual), so the error message was confusing.  It said, e.g., {code}expected:<14[92278]448000> but was:<14[60742]448000>{code} and yet the code says {code}assertEquals(parsedJSON.get("timestamp") + "", "1460742448000");{code}  Whoever fixes this, please fix that too.
> The same problem occurs in one test case of metron-platform/metron-parsers/src/test/java/org/apache/metron/parsers/asa/BasicAsaParserTest.java::testIp6Addr() , where the assertTrue() timestamp comparison fails.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)