[
https://issues.apache.org/jira/browse/FLUME-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235287#comment-13235287
]
[email protected] commented on FLUME-828:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3928/#review6201
-----------------------------------------------------------
Ship it!
+1
Thanks for the patch Brock. Can you please rebase it to the trunk and attache
it to the Jira.
- Arvind
On 2012-02-28 13:46:28, Brock Noland wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3928/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-02-28 13:46:28)
bq.
bq.
bq. Review request for Flume.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Changes SimpleEvent.toString() to include a human readable representation
of the body byte array.
bq.
bq.
bq. This addresses bug FLUME-828.
bq. https://issues.apache.org/jira/browse/FLUME-828
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. flume-ng-core/src/test/java/org/apache/flume/event/TestSimpleEvent.java
PRE-CREATION
bq. flume-ng-core/src/main/java/org/apache/flume/event/SimpleEvent.java
e0c3b45
bq.
bq. Diff: https://reviews.apache.org/r/3928/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Added two tests for the new code.
bq.
bq.
bq. Thanks,
bq.
bq. Brock
bq.
bq.
> 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
>
>
> 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
