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 Tue, 03 Mar 2015 00:20:04 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344125#comment-14344125
] 

Christopher Tubbs commented on ACCUMULO-3631:
---------------------------------------------

So, it seems like we're doing two things in this issue. The first is the one mentioned in
this issue... excluding duplicate slf4j artifacts from the classpath for the default value.
That, I have no concerns about doing in all versions.

Regarding the added classpath items... that's a separate (presumably, closely-related) issue.
I agree the risks are low, since the new paths are under /usr. However, I would prefer not
to make that change in 1.6, because it does also represent a change in security expectations
in a bugfix release. So, if we could make that change in only 1.7 and document the addition
to the release notes in 1.7, so users are aware, I'd be okay with that, also.

And finally, it seems like we really need to get a handle on our scripts and configuration,
especially as it relates to classpath / classloading. I think we need a long-term fix with
simple, consistent, well-defined behavior. Personally, I'd really like to see us eliminate
the whole accumulo-start / dynamic classloading mechanism, and make our launch scripts set
up a complete CLASSPATH environment before launching. If users need more than that, they can
specify a different default classloader when they launch the JVM (which we can make available,
if convenient to do so). And, we can still support a per-table context-classloader for the
per-table contexts also, without mucking about in accumulo-start. But, the specifics can be
worked/discussed in a separate issue. I doubt this is the last we'll see of classpath-related
confusing/issues, especially as users try to package/integrate Accumulo into more systems
(I hate to completely re-write the Accumulo launch scripts for systemd/JPackage in Fedora,
and I wouldn't be surprised if other downstream packagers haven't had a similar experience).

> 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