[
https://issues.apache.org/jira/browse/FLUME-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179236#comment-13179236
]
Kay Kay commented on FLUME-918:
-------------------------------
{quote}
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
{quote}
I agree, that EventProcessor-s are not specific to AvroSource/Sink but pretty
generic. (May be , would belong in the o.a.flume.event , package ? ) .
{quote}
What do you think about having ChannelEventProcessor be injected into
AvroSource / Sink (which would be concrete, but generic) rather than requiring
inheritance?
{quote}
I agree.
With AvroSource, currently it does management of underlying resources +
reference implementation of (AvroSource)Protocol as well.
Probably, either of those needs to be separated ?
> 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
