[
https://issues.apache.org/jira/browse/ACCUMULO-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044329#comment-15044329
]
Matt Dailey commented on ACCUMULO-2493:
---------------------------------------
OK, I wanted to check in before my PR got too big. Against the 1.7 branch, the
main changes I've made here:
* New class {{FormatterConfig}} handles configuration of Formatter objects
* To get around the Thread safety issues with DateFormat, I wrapped that in
{{DateFormatGenerator}} which also enables a Formatter to have both Thread
safety and per-instance DateFormat config.
* {{FormatterConfig}} is taken by {{Formatter.initialize}}, which broke the
interface for many classes throughout the non-public API, which were fixed
Here's a preview of the changes I've made unsquashed since it's not ready for a
PR yet (let me know if there's a better tool for this):
https://github.com/apache/accumulo/compare/1.7...matthew-dailey:ACCUMULO-2493-1.7?expand=1
Unit tests pass, but I'm getting a failure in the ReadWriteIT (will
investigate).
Any feedback is appreciated; feel free to let me know if an overhaul of the
Formatters should really be put into a separate issue that this one depends on.
> 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)
