-
Notifications
You must be signed in to change notification settings - Fork 9.2k
HADOOP-17675 LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException #2965
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
💔 -1 overall
This message was automatically generated. |
…ption As stated in this article: https://www.infoworld.com/article/2077344/find-a-way-out-of-the-classloader-maze.html A native thread has its context classloader set to null by default. If the context classloader which is used internally by JNDI to load a class is null, then the bootstrap classloader is used, according to the apidoc here: https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader- JNDI uses this form with the context classloader as can be seen here: https://github.com/openjdk/jdk11u/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java#L107 or here: https://github.com/openjdk/jdk8u/blob/master/jdk/src/share/classes/com/sun/jndi/ldap/VersionHelper12.java#L72 In Impala this call happens from a Thread created in native space, so in that case, the System/Application classloader loads LdapSslSocketFactory fine in LdapGroupsMapping.getDirContext() while creating the environment, but then InitialDirContext constructor gets to instantiation the LdapSslSocketFactory inside JNDI with the help of the linked VersionHelper impelmentations, and fails to load the class with the bootstrap classloader as context classloader is null. In order to solve this problem, we can safely use the classloader of the LdapGroupsMapping class, as it had to load the LdapSslSocketFactory class before.
|
💔 -1 overall
This message was automatically generated. |
sodonnel
approved these changes
May 4, 2021
Contributor
sodonnel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the mentioned articles and discussion with @fapifta this change makes sense to me. I am +1 to commit it.
kiran-maturi
pushed a commit
to kiran-maturi/hadoop
that referenced
this pull request
Nov 24, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As stated in this article:
https://www.infoworld.com/article/2077344/find-a-way-out-of-the-classloader-maze.html
A native thread has its context classloader set to null by default.
If the context classloader which is used internally by JNDI to load a class is
null, then the bootstrap classloader is used, according to the apidoc here:
https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-
JNDI uses this form with the context classloader as can be seen here:
https://github.com/openjdk/jdk11u/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java#L107
or here:
https://github.com/openjdk/jdk8u/blob/master/jdk/src/share/classes/com/sun/jndi/ldap/VersionHelper12.java#L72
In Impala this call happens from a Thread created in native space, so in that
case, the System/Application classloader loads LdapSslSocketFactory fine in
LdapGroupsMapping.getDirContext() while creating the environment, but then
InitialDirContext constructor gets to instantiation the LdapSslSocketFactory
inside JNDI with the help of the linked VersionHelper impelmentations,
and fails to load the class with the bootstrap classloader as context
classloader is null.
In order to solve this problem, we can safely use the classloader of the
LdapGroupsMapping class, as it had to load the LdapSslSocketFactory class
before.
NOTICE
Please create an issue in ASF JIRA before opening a pull request,
and you need to set the title of the pull request which starts with
the corresponding JIRA issue number. (e.g. HADOOP-XXXXX. Fix a typo in YYY.)
For more details, please see https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute