Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 16 Dec 2014 20:04:13 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12762084.1418759029000.36863.1418760253780@Atlassian.JIRA>
In-Reply-To: <JIRA.12762084.1418759029000@Atlassian.JIRA>
References: <JIRA.12762084.1418759029000@Atlassian.JIRA>
 <JIRA.12762084.1418759029493@arcas>
Subject: [jira] [Commented] (ACCUMULO-3424) Token class option always
 requires token property
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Elser commented on ACCUMULO-3424:
--------------------------------------

Looking at the history, it looks like some changes were made in ACCUMULO-1323 and maybe were misintepreted in ACCUMULO-1478? I can't see a reason for enforcing that we always have token properties from the initial change. If anyone has more context, please let me know.

> Token class option always requires token property
> -------------------------------------------------
>
>                 Key: ACCUMULO-3424
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3424
>             Project: Accumulo
>          Issue Type: Bug
>          Components: shell
>    Affects Versions: 1.6.0, 1.6.1
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.6.2, 1.7.0
>
>
> In testing out ACCUMULO-2815, I attempted to manually provide a KerberosToken to authenticate myself and then launch the shell, but ran into an issue. The KerberosToken (in its current state) needs no options: it's wholly functional on its own.
> {{accumulo shell -tc org.apache.accumulo.core.client.security.tokens.KerberosToken}}  gives an error
> {noformat}
> 2014-12-16 11:41:09,712 [shell.Shell] ERROR: com.beust.jcommander.ParameterException: Must supply either both or neither of '--tokenClass' and '--tokenProperty'
> {noformat}
> And providing an empty option just prints the help message {{accumulo shell -tc org.apache.accumulo.core.client.security.tokens.KerberosToken -l ""}}
> I'm guessing the latter is just how the JCommander DynamicParameter is implemented, but I don't see a reason why every authentication *must* have some properties provided to it.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)