accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3181) VolumeChooser usage doesn't always comply with implied API contract
Date Wed, 22 Oct 2014 12:19:33 GMT


Christopher Tubbs commented on ACCUMULO-3181:

bq. Could we unequivocally say that Volume Manager code is not public API at all?

To say this, what we'd mean would be that the interface is not public API at all, but the
ability to select between provided ones is available in the public API (because the chooser
was exposed as a configurable property in 1.6.x). That leaves it in a somewhat confusing state.
In 2.0.0, I hope to have this, along with other pluggable server-side components explicitly
in the public API. We could either move it there now, but this issue doesn't address or change
that at all. This issue is about cleaning up our internal usage of it, however it gets exposed
in the public API.

So, your point about the VolumeChooser being public API probably has less impact here, than
it would for ACCUMULO-3178, especially in the context of ACCUMULO-1641. I'll comment on ACCUMULO-3178.

> VolumeChooser usage doesn't always comply with implied API contract
> -------------------------------------------------------------------
>                 Key: ACCUMULO-3181
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.6.0, 1.6.1
>            Reporter: Christopher Tubbs
>            Assignee: Jenna Huston
>              Labels: api, interface, plugin
>             Fix For: 1.6.2, 1.7.0
> The VolumeChooser interface accepts a String array of "options" to choose from. This
method has no javadoc to explicitly declare what "options" mean, but given the name of the
class, and its intended purpose, derived from its usage, it appears that the Strings it receives
should represent volumes.
> However, some of the current usage is a bit lax in its parameter passing. In some cases,
what is passed are not volumes at all, but volumes concatenated with some path. This works
for the RandomVolumeChooser provided, but it should not be expected to work for any arbitrary
> The use of this API should consider the parameter to strictly be an array of volumes
(or Strings, representing volumes), since it's not a "PathChooser". Any concatenation of path
elements should be done outside the chooser, so we can define the API contract explicitly.
That means that some of the current usage should be altered to concatenate path elements after
the choose method returns.

This message was sent by Atlassian JIRA

View raw message