Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/1635
@mcgilman Thanks for the review. I definitely agree that the current use of
`cloneDuringInstanceClassLoading` allows for some confusing situations to arise
and makes it challenging for the framework to try and prevent
incorrect/unexpected behavior.
Thinking about this some more... the main reason for creating that flag was
because at component creation time we only have the class name (String) and
bundle for the component, and we need to make a decision about how far to go up
the class loader hierarchy when cloning resources.
If we had an instance of the component already then we could use the same
logic we have in other places where we look at the property descriptors that
reference controller service APIs, and determine which bundle they came from,
and then stop cloning resources when that bundle is reached. We already have
temp instances of every component when performing the service loading so we
could potentially cache these instances to do a lookup by className+bundle, and
possibly even replace a lot of our other temp component creation with look ups
to these temp instances.
If we did the above we would be more aggressively cloning class loader
resources, essentially always cloning until we see controller service API
references. For cases where we don't want this behavior we could possibly
change the meaning of `cloneDuringInstanceClassLoading`. It could instead be
used on the NAR where the component with `@RequiresInstanceClassLoading` lives
to indicate that the ancestor resources should be considered (stopping at first
CS API as described above). If `cloneDuringInstanceClassLoading` isn't provided
or is set to false, then a component with `@RequiresInstanceClassLoading` only
gets a copy of it's own NAR resources.
Example 1 - `PutHDFS` has `@RequiresInstanceClassLoading` and
`nifi-hadoop-nar` has `cloneDuringInstanceClassLoading` set to true, so the
`InstanceClassLoader` for `PutHDFS` gets all the resources from
`nifi-hadoop-nar` back to the first NAR that has a CS API referenced by`
PutHDFS`, or back to `nifi-jetty-nar` (exclusive).
Example 2 - `HBaseClientService_1_1_2` has `@RequiresInstanceClassLoading`
and `nifi-hbase-client-service-1-1-2-nar` does not have
`cloneDuringInstanceClassLoading`, so the `InstanceClassLoader` for
`HBaseClientService_1_1_2` gets only the resources from
`nifi-hbase-client-service-1-1-2`.
Thoughts?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
