[
https://issues.apache.org/jira/browse/HBASE-11259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013405#comment-14013405
]
Hudson commented on HBASE-11259:
--------------------------------
SUCCESS: Integrated in HBase-0.98 #322 (See
[https://builds.apache.org/job/HBase-0.98/322/])
HBASE-11259 Compression.java different compressions load system classpath
differently causing errors (Enoch Hsu) (apurtell: rev
c4b119ca85522f7062e140778c55089dcdf47251)
*
hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/Compression.java
> Compression.java different compressions load system classpath differently
> causing errors
> ----------------------------------------------------------------------------------------
>
> Key: HBASE-11259
> URL: https://issues.apache.org/jira/browse/HBASE-11259
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.99.0
> Reporter: Enoch Hsu
> Assignee: Enoch Hsu
> Priority: Minor
> Fix For: 0.99.0, 0.98.4
>
> Attachments: HBASE-11259.patch
>
>
> I stumbled upon this issue when testing Snappy compression on hbase tables
> with a webserver.
> On the webserver the system classpath of the server JVM did not include the
> path to hadoop-common.jar and since it is hardcoded to only retrieve the
> system classpath it ran into a NoClassDefFoundException using hte following
> call ClassLoader.getSystemClassLoader()
> However LZ4 compression works using this private method
> getClassLoaderForCodec() which attempts to load the threads classpath first
> and the system classpath last.
> I propose to change all the ClassLoader.getSystemClassLoader() calls to
> getClassLoaderForCodec() to allow for consistent behavior in loading
> compression classes and to also make it easier for users to make sure they do
> not run into RuntimeExceptions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
