[ 
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670833#comment-15670833
 ] 

ASF GitHub Bot commented on NIFI-2909:
--------------------------------------

GitHub user bbende opened a pull request:

    https://github.com/apache/nifi/pull/1232

    NIFI-2909 Fix logic in AbstractConfiguredComponent setProperties()

    for setting classpath resources in the InstanceClassLoader.
    
    Before if you updated other properties that were not classpath properties, 
it would end up resetting the classpath resources to an empty set, now it will 
only set the classpath resources when at least one classpath property is part 
of the setProperties call, so in the case where other properties are updated 
the class loader will not change.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/bbende/nifi NIFI-2909-2

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/nifi/pull/1232.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1232
    
----
commit 1b5222a2cdeb7c1f1920b748d46a300bfbd55902
Author: Bryan Bende <bbe...@apache.org>
Date:   2016-11-16T16:00:56Z

    NIFI-2909 Fix logic in AbstractConfiguredComponent setProperties() for 
setting classpath resources in the InstanceClassLoader

----


> 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)

Reply via email to