[jira] [Updated] (HADOOP-17675) LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException
[ https://issues.apache.org/jira/browse/HADOOP-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen O'Donnell updated HADOOP-17675: --- Fix Version/s: 3.4.0 3.3.1 > LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException > - > > Key: HADOOP-17675 > URL: https://issues.apache.org/jira/browse/HADOOP-17675 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.2.2 >Reporter: Tamas Mate >Assignee: István Fajth >Priority: Major > Labels: pull-request-available > Fix For: 3.3.1, 3.4.0 > > Attachments: stacktrace.txt > > Time Spent: 40m > Remaining Estimate: 0h > > Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when > it is called through native threads, such as Apache Impala does. > When a thread is attached to the VM, the currentThread's context classloader > is null, so when jndi internally tries to use the current thread's context > classloader to load the socket factory implementation, the > Class.forname(String, boolean, ClassLoader) method gets a null as the loader > uses the bootstrap classloader. > Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it > is loaded by the application classloader from its classpath. > As the bootstrap classloader does not have hadoop-common in its classpath, > when a native thread tries to use/load the LdapGroupsMapping class it can't > because the bootstrap loader can't load anything from hadoop-common. The > correct solution seems to be to set the currentThread's context classloader > to the classloader of LdapGroupsMapping class before initializing the jndi > internals, and then reset to the original value after, with that we can > ensure that the behaviour of other things does not change, but this failure > can be avoided as well. > Attached the complete stacktrace to this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17675) LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException
[ https://issues.apache.org/jira/browse/HADOOP-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HADOOP-17675: Labels: pull-request-available (was: ) > LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException > - > > Key: HADOOP-17675 > URL: https://issues.apache.org/jira/browse/HADOOP-17675 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.2.2 >Reporter: Tamas Mate >Assignee: István Fajth >Priority: Major > Labels: pull-request-available > Attachments: stacktrace.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when > it is called through native threads, such as Apache Impala does. > When a thread is attached to the VM, the currentThread's context classloader > is null, so when jndi internally tries to use the current thread's context > classloader to load the socket factory implementation, the > Class.forname(String, boolean, ClassLoader) method gets a null as the loader > uses the bootstrap classloader. > Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it > is loaded by the application classloader from its classpath. > As the bootstrap classloader does not have hadoop-common in its classpath, > when a native thread tries to use/load the LdapGroupsMapping class it can't > because the bootstrap loader can't load anything from hadoop-common. The > correct solution seems to be to set the currentThread's context classloader > to the classloader of LdapGroupsMapping class before initializing the jndi > internals, and then reset to the original value after, with that we can > ensure that the behaviour of other things does not change, but this failure > can be avoided as well. > Attached the complete stacktrace to this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17675) LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException
[ https://issues.apache.org/jira/browse/HADOOP-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Mate updated HADOOP-17675: Description: Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when it is called through native threads, such as Apache Impala does. When a thread is attached to the VM, the currentThread's context classloader is null, so when jndi internally tries to use the current thread's context classloader to load the socket factory implementation, the Class.forname(String, boolean, ClassLoader) method gets a null as the loader uses the bootstrap classloader. Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it is loaded by the application classloader from its classpath. As the bootstrap classloader does not have hadoop-common in its classpath, when a native thread tries to use/load the LdapGroupsMapping class it can't because the bootstrap loader can't load anything from hadoop-common. The correct solution seems to be to set the currentThread's context classloader to the classloader of LdapGroupsMapping class before initializing the jndi internals, and then reset to the original value after, with that we can ensure that the behaviour of other things does not change, but this failure can be avoided as well. Attached the complete stacktrace to this Jira. was: Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when the it is called through native threads, such as Apache Impala does. When a thread is attached to the VM, the currentThread's context classloader is null, so when jndi internally tries to use the current thread's context classloader to load the socket factory implementation, the Class.forname(String, boolean, ClassLoader) method gets a null as the loader, and uses the bootstrap classloader. Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it is loaded by the application classloader from its classpath. As the bootstrap classloader does not have hadoop-common in its classpath, when a native thread tries to use/load the LdapGroupsMapping class it can't because the bootstrap loader can't load anything from hadoop-common. The correct solution seems to be to set the currentThread's context classloader to the classloader of LdapGroupsMapping class before initializing the jndi internals, and then reset to the original value after, with that we can ensure that the behaviour of other things does not change, but this failure can be avoided as well. Attached the complete stacktrace to this Jira. > LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException > - > > Key: HADOOP-17675 > URL: https://issues.apache.org/jira/browse/HADOOP-17675 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.2.2 >Reporter: Tamas Mate >Assignee: István Fajth >Priority: Major > Attachments: stacktrace.txt > > > Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when > it is called through native threads, such as Apache Impala does. > When a thread is attached to the VM, the currentThread's context classloader > is null, so when jndi internally tries to use the current thread's context > classloader to load the socket factory implementation, the > Class.forname(String, boolean, ClassLoader) method gets a null as the loader > uses the bootstrap classloader. > Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it > is loaded by the application classloader from its classpath. > As the bootstrap classloader does not have hadoop-common in its classpath, > when a native thread tries to use/load the LdapGroupsMapping class it can't > because the bootstrap loader can't load anything from hadoop-common. The > correct solution seems to be to set the currentThread's context classloader > to the classloader of LdapGroupsMapping class before initializing the jndi > internals, and then reset to the original value after, with that we can > ensure that the behaviour of other things does not change, but this failure > can be avoided as well. > Attached the complete stacktrace to this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17675) LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException
[ https://issues.apache.org/jira/browse/HADOOP-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Mate updated HADOOP-17675: Attachment: stacktrace.txt > LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException > - > > Key: HADOOP-17675 > URL: https://issues.apache.org/jira/browse/HADOOP-17675 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.2.2 >Reporter: Tamas Mate >Assignee: István Fajth >Priority: Major > Attachments: stacktrace.txt > > > Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when > the it is called through native threads, such as Apache Impala does. > When a thread is attached to the VM, the currentThread's context classloader > is null, so when jndi internally tries to use the current thread's context > classloader to load the socket factory implementation, the > Class.forname(String, boolean, ClassLoader) method gets a null as the loader, > and uses the bootstrap classloader. > Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it > is loaded by the application classloader from its classpath. > As the bootstrap classloader does not have hadoop-common in its classpath, > when a native thread tries to use/load the LdapGroupsMapping class it can't > because the bootstrap loader can't load anything from hadoop-common. The > correct solution seems to be to set the currentThread's context classloader > to the classloader of LdapGroupsMapping class before initializing the jndi > internals, and then reset to the original value after, with that we can > ensure that the behaviour of other things does not change, but this failure > can be avoided as well. > Attached the complete stacktrace to this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17675) LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException
[ https://issues.apache.org/jira/browse/HADOOP-17675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] István Fajth updated HADOOP-17675: -- Description: Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when the it is called through native threads, such as Apache Impala does. When a thread is attached to the VM, the currentThread's context classloader is null, so when jndi internally tries to use the current thread's context classloader to load the socket factory implementation, the Class.forname(String, boolean, ClassLoader) method gets a null as the loader, and uses the bootstrap classloader. Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it is loaded by the application classloader from its classpath. As the bootstrap classloader does not have hadoop-common in its classpath, when a native thread tries to use/load the LdapGroupsMapping class it can't because the bootstrap loader can't load anything from hadoop-common. The correct solution seems to be to set the currentThread's context classloader to the classloader of LdapGroupsMapping class before initializing the jndi internals, and then reset to the original value after, with that we can ensure that the behaviour of other things does not change, but this failure can be avoided as well. Attached the complete stacktrace to this Jira. was: Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when the it is called through native threads, such as Apache Impala does. When a thread is attached to the VM, the context classloader is the bootstrap loader. Meanwhile the LdapGroupsMapping class is loaded by the application classloader from its classpath. Therefore when a native thread tries to use/load the LdapGroupsMapping class it can't to find it because it was loaded by another classloader and it can't load it either, because the jar is not on the bootstrap classloader's classpath. Attached the complete stacktrace to this Jira. > LdapGroupsMapping$LdapSslSocketFactory ClassNotFoundException > - > > Key: HADOOP-17675 > URL: https://issues.apache.org/jira/browse/HADOOP-17675 > Project: Hadoop Common > Issue Type: Improvement > Components: common >Affects Versions: 3.2.2 >Reporter: Tamas Mate >Assignee: István Fajth >Priority: Major > > Using LdapGroupsMapping with SSL enabled causes ClassNotFoundException when > the it is called through native threads, such as Apache Impala does. > When a thread is attached to the VM, the currentThread's context classloader > is null, so when jndi internally tries to use the current thread's context > classloader to load the socket factory implementation, the > Class.forname(String, boolean, ClassLoader) method gets a null as the loader, > and uses the bootstrap classloader. > Meanwhile the LdapGroupsMapping class and the SslSocketFactory defined in it > is loaded by the application classloader from its classpath. > As the bootstrap classloader does not have hadoop-common in its classpath, > when a native thread tries to use/load the LdapGroupsMapping class it can't > because the bootstrap loader can't load anything from hadoop-common. The > correct solution seems to be to set the currentThread's context classloader > to the classloader of LdapGroupsMapping class before initializing the jndi > internals, and then reset to the original value after, with that we can > ensure that the behaviour of other things does not change, but this failure > can be avoided as well. > Attached the complete stacktrace to this Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
