[
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644847#comment-15644847
]
ASF GitHub Bot commented on NIFI-2909:
--------------------------------------
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1156#discussion_r86828524
--- 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 --
What do you mean by "breaking"? If it changes the property such that the
processor becomes invalid, I think we are allowed to do that (the user just has
to remove the old property), as long as the default behavior is the same (which
it will be in this case since the new feature defaults to false). In any case
I'm good with writing a separate Jira to consider the other components that do
classloading stuff
> 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)
