That's really weird. I have no suggestions without digging into the code
myself. Sorry :\
Mike Miller wrote:
After further debugging, I don't think the problem is with the JCommander
classes directly. I have isolated the problem to be with something in the
accumulo shell. When I run the ChangeSecret utility as a standalone java
program on the command line, it has no problem accepting input. Any idea
what in the shell might be causing this issue? Is there something else
accepting input that could be interfering?
On Tue, Jul 12, 2016 at 12:02 PM, Mike Miller<[email protected]>
wrote:
It looks the problem is with the parsing of the arguments in the
JCommander classes. When I run ChangeSecret through the Eclipse debugger it
uses the DefaultConsole.readPassword method to read in the password and it
seems to take my input correctly. When I ran the utility through the
accumulo script and attached jdb, it looks like its using an internal class
called JDK6Console to read the password. The simple fact that it has a JDK
version in the name (I am running Java 1.8) gives me the feeling this might
be the problem. I will keep investigating.
On Tue, Jul 12, 2016 at 10:43 AM, Josh Elser<[email protected]> wrote:
Mike Miller wrote:
I was looking at the bug ACCUMULO-2971
<https://issues.apache.org/jira/browse/ACCUMULO-2971> but I am unable
to
get the ChangeSecret utility to run. I also noticed the bug 2972
<https://issues.apache.org/jira/browse/ACCUMULO-2972> which states the
documentation should instruct the user to run the utility as so:
accumulo org.apache.accumuloserver.util.ChangeSecret
I have a standalone instance of 1.7.2 setup on my machine. I am running
the
utility as myself, which is also the user that is running Hadoop and who
has control over the files in HDFS, but when the utility prompts for the
passwords, it is only letting me enter a single keystroke for each
password. Then I get an
org.apache.zookeeper.KeeperException$NoAuthException because I am unable
to
enter the passwords correctly.
That's weird.
Christopher suggested that it might be an issue with the latest JLine jar
(2.11) so I pulled down the older jar (2.10) and replaced the newer jar
in
my lib. This didn't seem to have any effect. Could this be an issue with
my
local install?
It might just be broken. It's not something that is commonly used, and
has probably atrophied.
Have you tried to attach a remote debugger to the process (you can put
the JVM properties into ACCUMULO_GENERAL_OPTS via accumulo-env.sh) to trace
through what it's doing?
