[
https://issues.apache.org/jira/browse/METRON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Foley updated METRON-648:
------------------------------
Description:
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.
was:
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.
> 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)
