[
https://issues.apache.org/jira/browse/FLUME-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179192#comment-13179192
]
E. Sammer commented on FLUME-918:
---------------------------------
Kay Kay:
I'm looking over your patch now. Generally, I agree with the idea of decoupling
the notion of sources and sinks from event processors. I like the idea of
having a ChannelEventProcessor (or maybe just EventProcessor). I wonder if we
should extend this to be Flume NG's version of decorators. Maybe each source
and sink can be configured with an optional list of pre-process and
post-process EventProcessors as well as single EventProcessor that actually
handles the message. Just thinking out loud.
I do have some style nits with the review (I'll mark it up), but more
importantly, a strong urge to avoid extension by inheritance. What do you think
about having ChannelEventProcessor be injected into AvroSource / Sink (which
would be concrete, but generic) rather than requiring inheritance?
> customizable avro based processing
> ----------------------------------
>
> Key: FLUME-918
> URL: https://issues.apache.org/jira/browse/FLUME-918
> Project: Flume
> Issue Type: Improvement
> Components: Sinks+Sources
> Affects Versions: NG alpha 2
> Reporter: Kay Kay
> Assignee: Kay Kay
> Fix For: v1.1.0
>
> Attachments: FLUME-918.patch
>
>
> Currently, flume ships with a flume.avdl that has a reference implementation
> of a AvroSource / AvroSink , to deal with the default flume transports (
> Event / Channel - s) .
> We need to customize the avro schema that goes in, for our purposes - but
> would still like to reuse a majority of code of AvroSource / AvroSink that
> does the marshalling/ unmarshalling.
--
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
