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

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_r86822779
  
    --- 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 --
    
    They could be... my thinking was to initially get this capability in place 
and then maybe the people who worked on those components could determine if 
they should be refactored to use this capability, or if there is some reason 
why they should be left as is.


> 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