[
https://issues.apache.org/jira/browse/ACCUMULO-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341258#comment-14341258
]
Christopher Tubbs commented on ACCUMULO-3631:
---------------------------------------------
A bit of backstory for newcomers:
So, the primary problem at play is that some client code (in particular, the
shell) has always assumed (improperly) that it could access the
one-config-to-rule-them-all configuration for the server components
(accumulo-site.xml, found on the classpath). Once people other than admins who
are debugging a system started using the shell to explore their data and
perform simple operations, it became clear that things would not work (as is)
without specifying additional configuration to connect to Accumulo. So, we
added command-line configuration options to use a ZooKeeperInstance.
However, people still wanted the ability to avoid specifying the command-line
configuration options for backwards compatibility. At that point, we should
have added explicit client configuration options, but we settled for the fact
that the client didn't actually need the *real* accumulo-site.xml file, but any
equivalent one (without the sensitive bits for the server) on the classpath
would suffice. When actual client configuration was enabled (as part of
ACCUMULO-1009), the shell and other admin utilities did not replace all uses of
accumulo-site.xml with this client configuration (and, honestly, I'm not
entirely sure how we'd do that).
The workaround we've always recommended is simply to create a different
classpath for the client code, which contains an accessible (and non-sensitive)
accumulo-site.xml file for these cases. This remains a valid workaround.
> Exclude 'slf4j' artifacts from classpath in default value for
> general.classpaths
> --------------------------------------------------------------------------------
>
> Key: ACCUMULO-3631
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3631
> Project: Accumulo
> Issue Type: Bug
> Affects Versions: 1.6.0, 1.6.1, 1.6.2
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Blocker
> Fix For: 1.7.0, 1.6.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Was testing out some Ambari integration for Accumulo that [~billie.rinaldi]
> and [~mwaineo] have been working on (AMBARI-5265) and found that, despite
> accumulo-site.xml having jars starting with slf4j excluded from the
> classpath, the shell would complain about duplicate slf4j-log4j12 jars on the
> classpath.
> Turns out, because access to accumulo-site.xml was restricted (and we only
> had client.conf to use), we fell back on the default value for
> general.classpaths defined in AccumuloClassLoader. A short-term fix is to
> update the value there to match what's in our site template.
> I'll add another issue for a long term fix to add classpath support to client
> configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
