[
https://issues.apache.org/jira/browse/FLUME-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211650#comment-13211650
]
Arvind Prabhakar commented on FLUME-978:
----------------------------------------
I agree that at the basic level all configuration is expressed as strings.
However, once an object has been resolved, it may be beneficial to cache it
within the context implementation to ensure that it can be obtained quickly if
necessary. We can address the caching later too if it becomes evident that it
will help with performance of the system.
> Context interface is too basic requiring boilerplate user code
> --------------------------------------------------------------
>
> Key: FLUME-978
> URL: https://issues.apache.org/jira/browse/FLUME-978
> Project: Flume
> Issue Type: Improvement
> Reporter: Brock Noland
> Assignee: Brock Noland
>
> Flume is filled with examples like so:
> batchSize = Integer.parseInt(context.get("batch-size", String.class));
> if (batchSize == null) {
> batchSize = defaultBatchSize;
> }
> from AvroSink. The Context object should provide at a minimum:
> * getBoolean(key)
> * getBoolean(key, default)
> * getInteger(key)
> * getInteger(key, default)
> * getLong(key)
> * getLong(key, default)
> Additionally, the Context object outside of tests, is populated via
> FlumeConfiguration which in the end is a properties file. In this common
> case, all the values in the Context object will be Strings. In this case, if
> we do the obvious and simply provide wrappers for getBoolean, we end up
> executing:
> return Boolean.class.cast(String);
> Users of the Context object should not care where the values come from, only
> that they will be returned the correct object type.
--
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
