You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Sangjin Lee (JIRA)" <ji...@apache.org> on 2015/04/14 18:36:13 UTC

[jira] [Commented] (HADOOP-11831) isolated classloader does not handle packages that are split between system classpath and app classpath

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

Sangjin Lee commented on HADOOP-11831:
--------------------------------------

We could try to override the system class list to have exclusion rules for these odd ball classes, but that approach won't really scale.

Another possibility is to allow the application classloader to fall back on the app classpath for a system class if it cannot load it from the system classpath. But I think we need to think through the implications of doing that. the semantics of system classes is they should be exclusively owned by the underlying system (system = container, framework, JDK, ...) and one should not fall back on the user classpath to load system classes.

Also, in practice, we need to think about security issues and whether there would be collisions between multiple versions of the same class (manifested as issues like loader constraint violation LinkageErrors).

> isolated classloader does not handle packages that are split between system classpath and app classpath
> -------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-11831
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11831
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: Sangjin Lee
>            Assignee: Sangjin Lee
>
> We've seen a case where the isolated classloader fails if user code needs classes that are part of the system classes package but are not included in the "system".
> One example we see is class org.w3c.dom.ElementTraversal:
> {noformat}
> java.lang.ClassNotFoundException: org.w3c.dom.ElementTraversal
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.apache.hadoop.util.ApplicationClassLoader.loadClass(ApplicationClassLoader.java:202)
> at org.apache.hadoop.util.ApplicationClassLoader.loadClass(ApplicationClassLoader.java:170)
> ... 47 more
> {noformat}
> The org.w3c.dom package is included in the system class packages as it is provided by the JDK itself. However, this particular class (ElementTraversal) does not exist in the JDK. In this case, it was included in a Xerces library the user brought. However, since the package is declared as system classes, the application classloader will not look at the app classpath to locate this class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)