hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11831) isolated classloader does not handle packages that are split between system classpath and app classpath
Date Tue, 14 Apr 2015 16:36:13 GMT

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

Mime
View raw message