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 01:40:06 GMT

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

Mime
View raw message