You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/03/05 22:35:00 UTC

[jira] [Commented] (METRON-1299) MetronError tests fail if hostname isn't set

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

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

Github user justinleet commented on the issue:

    https://github.com/apache/metron/pull/924
  
    @cestella Bump


> MetronError tests fail if hostname isn't set
> --------------------------------------------
>
>                 Key: METRON-1299
>                 URL: https://issues.apache.org/jira/browse/METRON-1299
>             Project: Metron
>          Issue Type: Bug
>    Affects Versions: 0.4.1
>         Environment: openSUSE Tumbleweed 20171102, OpenJDK 1.8.0_144
>            Reporter: Stuart Bertram
>            Assignee: Otto Fowler
>            Priority: Major
>
> If I run "mvn package" in the root Metron directory then compilation fails because of a null reference in  {{./metron-platform/metron-common/src/test/java/org/apache/metron/common/error/MetronErrorTest.java}}. This happens in {{getJSONObjectShouldReturnBasicInformation}} on line 56 because  {{errorJSON.get(Constants.ErrorFields.HOSTNAME.getName())}} is assumed to return a string and the {{length()}} method is called on it. Because the assert doesn't use a message then no obvious reason why it fails is logged.
> The underlying problem is that {{metron-platform/metron-common/src/main/java/org/apache/metron/common/error/MetronError.java}} falls through to a {{catch}} block in {{addHostname()}} when {{netAddress.getLocalHost().getHostName()}} exceptions with {{Name or service not known}} for the host name.
> Setting a hostname that resolves is a build requirement that is out of Metron's control, but if the code specifically handles the fact that it won't always be retrieved then it seems problematic to have tests that assume it works _and_ not make it clear what the failure is when it occurs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)