[
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629070#comment-15629070
]
ASF GitHub Bot commented on NIFI-2909:
--------------------------------------
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.
> Provide a framework mechanism for loading additional classpath resources
> ------------------------------------------------------------------------
>
> Key: NIFI-2909
> URL: https://issues.apache.org/jira/browse/NIFI-2909
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Bryan Bende
> Assignee: Bryan Bende
> Fix For: 1.1.0
>
>
> We currently have several components with a property for specifying
> additional classpath resources (DBCP connection pool, scripting processors,
> JMS). Each of these components is responsible for handling this in its own
> way.
> The framework should provide a more integrated solution to make it easier for
> component developers to deal with this scenario. Some requirements that need
> to be met by this solution:
> - Multiple instances of the same component with different resources added to
> the classpath and not interfering with each other (i.e. two DBCP connection
> pools using different drivers)
> - Ability to modify the actual ClassLoader of the component to deal with
> frameworks that use Class.forName() without passing in a ClassLoader, meaning
> if a processor loads class A and class A calls Class.forName(classBName),
> then class B needs to be available in the ClassLoader that loaded the
> processor's class which in turn loaded class A
> - A component developer should be able to indicate that a given
> PropertyDescriptor represents a classpath resource and the framework should
> take care of the ClassLoader manipulation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
