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? > >> >> >>> > >> >> >> > >> >> > > >> >> > >> > > >> > > > > >
