[jira] [Updated] (FLUME-828) LoggerSink representation of the event's body isn't too useful

["E. Sammer (Updated) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLUME-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

E. Sammer updated FLUME-828:
----------------------------

    Fix Version/s: NG alpha 3
         Assignee: E. Sammer

Scheduling for alpha 3 and assigning to myself.
                
> LoggerSink representation of the event's body isn't too useful
> --------------------------------------------------------------
>
>                 Key: FLUME-828
>                 URL: https://issues.apache.org/jira/browse/FLUME-828
>             Project: Flume
>          Issue Type: Bug
>          Components: Sinks+Sources
>    Affects Versions: NG alpha 1
>            Reporter: Will McQueen
>            Assignee: E. Sammer
>             Fix For: NG alpha 3
>
>
> LoggerSink logs entries to console that looks like this:
>      Event: { headers:{} body:[B@5c1ae90c }
> ...where the body is just "getClass().getName() + "@" + Integer.toHexString(hashCode())". The "getClass().getName() will always resolve to [B.
> The issue seems to be how can we represent a SimpleEvent's payload as a String, when the payload is some arbitrary byte array... the array's bytes could represent encoded ascii chars, encoded UTF-8 chars, or binary data such as an encrypted payload. If we default to ASCII translation for everything, then the resulting String won't be useful for binary payloads since not all 256 possible bytes have equivalent printable ASCII chars. Here's one idea:
> For each event body, we can print up to the first 16 bytes in hex format. If there are >16 bytes, then print a "..." suffix at the end. The output would look similar to what you get with unix "hexdump -C". Here's what a sample output from LoggerSink would look like:
>      Event: { headers:{} body: 00000000 54 68 65 20 71 75 69 63 6B 20 62 72 6F 77 6E 20 |The quick brown | ... }
> ...where both the hex and the ascii are displayed for the first 16 chars.
> Is it the most useful representation of the body? Probably not. Is it as least more useful than printing "[B@" + Integer.toHexString(hashCode())"? I think so.
> The commons io lib has a useful HexDump.dump cmd we can leverage.
> Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira