[
https://issues.apache.org/jira/browse/FLUME-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235414#comment-13235414
]
Hudson commented on FLUME-828:
------------------------------
Integrated in flume-trunk #136 (See
[https://builds.apache.org/job/flume-trunk/136/])
FLUME-828. Fix LoggerSink represenation of event body.
(Brock Noland via Arvind Prabhakar) (Revision 1303664)
Result = SUCCESS
arvind : http://svn.apache.org/viewvc/?view=rev&rev=1303664
Files :
* /incubator/flume/trunk/flume-ng-sdk/pom.xml
*
/incubator/flume/trunk/flume-ng-sdk/src/main/java/org/apache/flume/event/SimpleEvent.java
*
/incubator/flume/trunk/flume-ng-sdk/src/test/java/org/apache/flume/event/TestSimpleEvent.java
> 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: Improvement
> Components: Sinks+Sources
> Affects Versions: NG alpha 1
> Reporter: Will McQueen
> Assignee: Brock Noland
> Fix For: v1.2.0
>
> Attachments: FLUME-828-0.patch, FLUME-828-1.patch, FLUME-828-2.patch,
> FLUME-828-3.patch
>
>
> 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
