[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900026#comment-15900026
]
Christopher Tubbs commented on ACCUMULO-4600:
---------------------------------------------
I think maybe another solution might work: create a
{{SiteConfiguration.getInstanceOrDefault(...)}} method specifically for this
shell use case. We have to be careful not to override the client config if it's
available, but then sanely fall back on the site config, but only if that site
config is accessible.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---------------------------------------------------------------
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
> Affects Versions: 1.7.3
> Reporter: Josh Elser
> Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
