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