accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3631) Exclude 'slf4j' artifacts from classpath in default value for general.classpaths
Date Sat, 28 Feb 2015 02:53:04 GMT

    [ 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)

Mime
View raw message