Github user olegz commented on the issue:
https://github.com/apache/nifi/pull/1156
@bbende While i am still reviewing and testing, I think it is worth
clarifying what per-instance really means. What I am trying to say is the fact
that property values can be changed multiple times per single instance of the
component and while it's ok for most properties, changing values for things
like additional classpath will most likely result in unpredictable type
resolution exceptions.
For example; If a JAR provided as property value is changed after a
component already had a chance to run and certain classes were already loaded
from the previous JAR while new versions (compatible or not) of the same
classes are coming with the new JAR.
Alternatively, we can take a slightly different approach and address it
similarly to the way it is addressed in SpringContextProcessor where additional
classpath has no relation to the instance of the component and only exists
while component is in active state (e.g., CS-enabled, Proc-started, etc.)
To summarize; we either have to document the limitations and side-effects
of the per-instance approach or change it to per-activation.
---
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.
---
