You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Enoch Hsu (JIRA)" <ji...@apache.org> on 2014/05/28 23:47:08 UTC

[jira] [Updated] (HBASE-11259) Compression.java different compressions load system classpath differently causing errors

     [ https://issues.apache.org/jira/browse/HBASE-11259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Enoch Hsu updated HBASE-11259:
------------------------------

    Status: Patch Available  (was: Open)

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