Now that we got to the bottom of this issue, I created a JIRA ticket so I can fix it! https://issues.apache.org/jira/browse/ACCUMULO-4374
On Thu, Jul 14, 2016 at 3:36 PM, Christopher <[email protected]> wrote: > Ah, I see. So the KeywordExecutable stuff is required to call the no-arg > constructor to load classes, yet the one in the Shell is actually doing > work. (ServiceLoader, which KeywordExecutable uses, is best used when > instantiating lightweight factories.) > > So, there are two options: > > 1. Make the no-arg constructor in the Shell do less work. (this should be > easy, because it's only called by Shell.main, and main can just pass the > parameters that the no-arg constructor was assuming) > 2. Move the KeywordExecutable stuffs for Shell into a minimal > launcher/factory class for Shell; see **/MasterExecutable.java for another > case where I had to do this. > > On Thu, Jul 14, 2016 at 3:18 PM Mike Miller <[email protected]> > wrote: > > > I think I have isolated the problem and think this may be a bug. The > > interference is happening when jline.console.ConsoleReader gets > > instantiated in the constructor of org.apache.accumulo.shell.Shell. Even > > though I am not starting the shell with bin/accumulo, it is still being > > instantiated by the ServiceLoader in o.a.a.start.Main. See the evidence > of > > my manually thrown exception and stacktrace below. > > Shell() called from... > > java.lang.Exception > > at org.apache.accumulo.shell.Shell.<init>(Shell.java:247) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > Method) > > at > > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > > > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > > at java.lang.Class.newInstance(Class.java:442) > > at > > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) > > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > > at org.apache.accumulo.start.Main.checkDuplicates(Main.java:223) > > at org.apache.accumulo.start.Main.getExecutables(Main.java:215) > > at org.apache.accumulo.start.Main.main(Main.java:78) > > > > I tested ChangeSecret again with an empty constructor in > o.a.a.shell.Shell > > and it has no problem reading in the passwords. This seems like a bug > > between the two classes but I am just not sure which one is the guilty > > party. > > > > > > On Thu, Jul 14, 2016 at 7:36 AM, Mike Miller <[email protected]> > > wrote: > > > > > Sorry for the confusion, I was thinking that > > > org.apache.accumulo.shell.Shell gets instantiated when calling > > bin/accumulo > > > org.apache.accumulo.server.util.ChangeSecret. I think you are right > about > > > the problem being with the classpath setup by the bin/accumulo script. > > > > > > On Wed, Jul 13, 2016 at 6:33 PM, Christopher <[email protected]> > > wrote: > > > > > >> Oh wait, strike that. We don't have a shell command for this. I think > I > > >> misunderstood your use of the word "shell". > > >> If I understand correctly, doing this works: > > >> CLASSPATH=.... java org.apache.accumulo.server.util.ChangeSecret > > >> but this doesn't: > > >> bin/accumulo org.apache.accumulo.server.util.ChangeSecret > > >> > > >> This would imply that the thing which is interfering is something > coming > > >> in > > >> from the classpath which is set up by bin/accumulo. > > >> > > >> On Wed, Jul 13, 2016 at 6:27 PM Christopher <[email protected]> > > wrote: > > >> > > >> > The shell does change the input charset (to latin1, I believe), so > > maybe > > >> > that has an effect? > > >> > > > >> > > > >> > On Wed, Jul 13, 2016 at 4:22 PM Josh Elser <[email protected]> > > >> wrote: > > >> > > > >> >> 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? > > >> >> >>> > > >> >> >> > > >> >> > > > >> >> > > >> > > > >> > > > > > > > > >
