[
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633848#comment-15633848
]
ASF GitHub Bot commented on NIFI-2909:
--------------------------------------
Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/1156
@olegz I pushed up a second commit that with the change that I described
above, and also some of the changes from your feedback. Unfortunately I had
already rebased my branch before you had started reviewing, so i ended up
having to force push, but I left it as two commits where the first one has the
stuff you already looked at, and the second commit has changes after that.
I think the remaining discussion point is mostly around how restrictive we
get regarding what happens when one or more resources can't be found. I
understand the point about what happens if something that is necessary can't be
loaded, but I also want to give flexibility to the developers using this
feature. There may be cases where someone wants to provide a couple of
directories that are common locations for a given library, and if found then
load whatever is found, but if not then maybe they don't care. One option might
be to provide a validator that uses ClassLoader.getURLsforClasspath to validate
everything resolves, and then document that this is available, but not enforce
that it is always used.
> 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)
