[
https://issues.apache.org/jira/browse/NIFI-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890892#comment-15890892
]
ASF GitHub Bot commented on NIFI-3520:
--------------------------------------
Github user jtstorck commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1539#discussion_r103770451
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/ExtensionManager.java
---
@@ -199,8 +199,20 @@ public static ClassLoader getClassLoader(final String
classType, final String in
// then make a new InstanceClassLoader that is a full copy of
the NAR Class Loader, otherwise create an empty
// InstanceClassLoader that has the NAR ClassLoader as a parent
if (requiresInstanceClassLoading.contains(classType) &&
(registeredClassLoader instanceof URLClassLoader)) {
- final URLClassLoader registeredUrlClassLoader =
(URLClassLoader) registeredClassLoader;
- instanceClassLoader = new
InstanceClassLoader(instanceIdentifier, classType,
registeredUrlClassLoader.getURLs(), registeredUrlClassLoader.getParent());
+ final Set<URL> classLoaderResources = new HashSet<>();
+
+ // if the registered class loader is a NAR class loader
then walk the chain of class loaders until
+ // finding a non-NAR class loader, and build up a list of
all URLs along the way
+ while (registeredClassLoader != null &&
registeredClassLoader instanceof NarClassLoader) {
+ final NarClassLoader narClassLoader = (NarClassLoader)
registeredClassLoader;
+ for (URL classLoaderResource :
narClassLoader.getURLs()) {
+ classLoaderResources.add(classLoaderResource);
+ }
+ registeredClassLoader = narClassLoader.getParent();
+ }
--- End diff --
@olegz This PR will be updated with a different approach. This change will
be reverted, overall.
> HDFS processors experiencing Kerberos "impersonate" errors
> -----------------------------------------------------------
>
> Key: NIFI-3520
> URL: https://issues.apache.org/jira/browse/NIFI-3520
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.0.0, 1.1.0, 1.1.1, 1.0.1
> Reporter: Jeff Storck
> Assignee: Jeff Storck
>
> When multiple Kerberos principals are used between multiple HDFS processors,
> the processor instances will be able to login to Kerberos with their
> configured principals initially, but will not properly relogin.
> For example, if there are two PutHDFS processors, one configured as
> us...@example.com, and the other as us...@example.com, they will both login
> with the KDC correctly and be able to transfer files to HDFS. Once one of
> the PutHDFS processors attempts to relogin, it may end up being logged in as
> the principal from the other PutHDFS processor. The principal contexts end
> up getting switched, and the hadoop client used by the processor will attempt
> to proxy requests from one user through another, resulting in the following
> exception:
> {panel}Failed to write to HDFS due to
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException):
> User: us...@example.com is not allowed to impersonate
> us...@example.com{panel}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
