[jira] [Commented] (ACCUMULO-3631) Exclude 'slf4j' artifacts from classpath in default value for general.classpaths

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

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