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)