[
https://issues.apache.org/jira/browse/ACCUMULO-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341165#comment-14341165
]
Christopher Tubbs commented on ACCUMULO-3631:
---------------------------------------------
I'm concerned about the change in commit
[f47fdfe|https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f47fdfe].
On ACCUMULO-3338, when the change was added to the template. In the [discussion
on that
thread|https://issues.apache.org/jira/browse/ACCUMULO-3338?focusedCommentId=14213959&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14213959],
it was *explicitly* argued that these changes were acceptable because they
represented *example* configurations. By adding the additional locations for
certain downstream packaging conventions to the default value of the classpath,
these additions now represent *more* than example configurations, and as they
are hard-coded directly into the default behavior of Accumulo, which matters in
production (for reasons outlined in this issue, and probably other reasons,
also).
While I think a narrower change to address the slf4j issue outlined here is a
good short-term fix, I think we need to get some consensus on what the default
classpaths should be, and the risks associated with them being too broad (as
described [in the comment
thread|https://issues.apache.org/jira/browse/ACCUMULO-3338?focusedCommentId=14213984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14213984]
on ACCUMULO-3338.
I'm also opposed to these additional items on the default classpath for 1.6,
due to the fact that it intrinsically changes the security risks and
considerations admins have made for that version, across a bugfix release, and
I think such a change is inappropriate in a bugfix release.
Until we have consensus, I'm inclined to -1 this change and revert the commit,
and favor of a narrower change to address the immediate problem of slf4j.
Ideally, I'd like to consider changing the default classpath to empty in 1.7
and rely on the examples/template to populate it, but I'd understand if we
wanted to preserve the existing behavior (with the slf4j fix), only because
it's expected and familiar.
> 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
> 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)
