[
https://issues.apache.org/jira/browse/ACCUMULO-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15039659#comment-15039659
]
Josh Elser commented on ACCUMULO-2493:
--------------------------------------
bq. Since adding an int maxLength option to Formatter.initialize would cause
this issue to be brought up again whenever someone wants another configuration
option down the road, I was thinking of changing Formatter.intialize to accept
a hadoop Configuration object and let Formatters configure themselves.
Good thinking. Convention-wise, we tend to make our own configuration objects
instead of leveraging Hadoop Configuration objects. Examples include
{{BatchWriterConfig}}, {{ClientConfiguration}}, {{ConditionalWriterConfig}}.
I'd tend to go that route just for some consistency with the rest of the public
API (assuming Formatters will eventually get pushed into the public API). WDYT?
> BinaryFormatter needs to be refactored
> --------------------------------------
>
> Key: ACCUMULO-2493
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2493
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Reporter: Mike Drob
> Assignee: Matt Dailey
> Labels: newbie
> Fix For: 1.7.1, 1.8.0
>
>
> BinaryFormatter is currently used in a couple places in the shell, but the
> code is hard to read and understand. There is a static getlength, which is
> actually a setter, and all the instance calls end up going through
> unnecessary static methods.
> This combination makes it hard to reuse BinaryFormatter objects, or even use
> multiple, since the static state is likely to conflict.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
