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

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

Github user bbende commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/1156#discussion_r86839408
  
    --- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-hbase-client-service-api/src/main/java/org/apache/nifi/hbase/HBaseClientService.java
 ---
    @@ -67,6 +67,14 @@
                 .defaultValue("1")
                 .build();
     
    +    PropertyDescriptor PHOENIX_CLIENT_JAR_LOCATION = new 
PropertyDescriptor.Builder()
    +            .name("Phoenix Client JAR Location")
    +            .description("The full path to the Phoenix client JAR. 
Required if Phoenix is installed on top of HBase.")
    +            .addValidator(StandardValidators.FILE_EXISTS_VALIDATOR)
    +            .expressionLanguageSupported(true)
    +            .dynamicallyModifiesClasspath(true)
    --- End diff --
    
    I don't see why it would be considered breaking... in most of the cases 
nothing is changing for the end user. Lets take DBCP Connection Pool, the same 
property exists before and after, its just the class loading code being moved 
from in the component to handled by the framework.


> 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