Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6265017BEB for ; Wed, 22 Oct 2014 05:24:34 +0000 (UTC) Received: (qmail 1605 invoked by uid 500); 22 Oct 2014 05:24:34 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 1552 invoked by uid 500); 22 Oct 2014 05:24:34 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 1535 invoked by uid 99); 22 Oct 2014 05:24:34 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Oct 2014 05:24:34 +0000 Date: Wed, 22 Oct 2014 05:24:34 +0000 (UTC) From: "Sean Busbey (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ACCUMULO-3181) VolumeChooser usage doesn't always comply with implied API contract MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACCUMULO-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179604#comment-14179604 ] Sean Busbey commented on ACCUMULO-3181: --------------------------------------- bq. Since this component is not strictly public API Could we unequivocally say that Volume Manager code is not public API at all? The multi-volume stuff is all still very new and we need room to work in changes as they come up. Esp while our public API statements don't cover server-side components. Users who are going beyond use of it to add their own choosers need to be cognizant of the fact that they are on the far end of a limb. > VolumeChooser usage doesn't always comply with implied API contract > ------------------------------------------------------------------- > > Key: ACCUMULO-3181 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3181 > 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 implementation. > 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 (v6.3.4#6332)