accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2493) BinaryFormatter needs to be refactored
Date Fri, 04 Dec 2015 20:27:11 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15042183#comment-15042183
] 

Christopher Tubbs commented on ACCUMULO-2493:
---------------------------------------------

I think we'd like to move away from Hadoop configuration objects whenever we're not interacting
with Hadoop features/APIs, because we don't want to be tightly coupled to the Hadoop libraries,
especially in our client code. We've been doing little things here and there to try to avoid
further coupling.

A couple of options which have been considered before:

Properties - pro: built-in, generic, and flexible; con: not self-descriptive about possible
options
Commons Configuration - similar pros-cons as Properties, but maybe some additional tools/hierarchical
parsing, options for file formats, etc.

I've been playing around with another kind of abstraction which can add some self-descriptiveness
to a generic configuration store like Properties/Commons Configuration, but it's far from
fully fleshed out. The basic idea is that you'd specify a Class containing a set of typed
Keys as the definition of your configuration options, and pass in your configuration source
for it to parse, validate, and access. https://github.com/revelc/blazon

Our current practice, however, tends to be writing fluent configuration builders which are
narrowly scoped to the function in which they are being used (like BatchWriter, etc.)

> 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)

Mime
View raw message