[
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629252#comment-15629252
]
ASF GitHub Bot commented on NIFI-2909:
--------------------------------------
Github user olegz commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1156#discussion_r86164431
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core-api/src/main/java/org/apache/nifi/controller/AbstractConfiguredComponent.java
---
@@ -141,48 +191,64 @@ public void setProperty(final String name, final
String value) {
* @return true if removed; false otherwise
* @throws java.lang.IllegalArgumentException if the name is null
*/
- @Override
- public boolean removeProperty(final String name) {
+ private boolean removeProperty(final String name) {
if (null == name) {
throw new IllegalArgumentException();
}
- lock.lock();
- try {
- verifyModifiable();
-
- try (final NarCloseable narCloseable =
NarCloseable.withComponentNarLoader(component.getClass())) {
- final PropertyDescriptor descriptor =
component.getPropertyDescriptor(name);
- String value = null;
- if (!descriptor.isRequired() && (value =
properties.remove(descriptor)) != null) {
-
- if (descriptor.getControllerServiceDefinition() !=
null) {
- if (value != null) {
- final ControllerServiceNode oldNode =
serviceProvider.getControllerServiceNode(value);
- if (oldNode != null) {
- oldNode.removeReference(this);
- }
- }
- }
+ final PropertyDescriptor descriptor =
component.getPropertyDescriptor(name);
+ String value = null;
+ if (!descriptor.isRequired() && (value =
properties.remove(descriptor)) != null) {
- try {
- component.onPropertyModified(descriptor, value,
null);
- } catch (final Exception e) {
- // nothing really to do here...
+ if (descriptor.getControllerServiceDefinition() != null) {
+ if (value != null) {
+ final ControllerServiceNode oldNode =
serviceProvider.getControllerServiceNode(value);
+ if (oldNode != null) {
+ oldNode.removeReference(this);
}
-
- return true;
}
}
- } finally {
- lock.unlock();
+
+ try {
+ component.onPropertyModified(descriptor, value, null);
+ } catch (final Exception e) {
+ // nothing really to do here...
+ }
+
+ return true;
}
+
return false;
}
+ /**
+ * Adds all of the modules identified by the given module paths to the
InstanceClassLoader for this component.
+ *
+ * @param modulePaths a list of module paths where each entry can be a
comma-separated list of multiple module paths
+ */
+ private void processClasspathModifiers(final Set<String> modulePaths) {
+ try {
+ final URL[] urls =
ClassLoaderUtils.getURLsForClasspath(modulePaths, null, true);
+
+ final ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
+ if (!(classLoader instanceof InstanceClassLoader)) {
+ // Really shouldn't happen, but if we somehow got here and
don't have an InstanceClassLoader then log a warning and move on
+ logger.warn("Unable to modify the classpath for {},
expected InstanceClassLoader, but found {}",
+ new Object[] { name,
classLoader.getClass().getName()});
+ return;
--- End diff --
I am wondering if this should really be a fatal condition. Let's say I have
a processor that utilizes this mechanism and the additional classpath is a
required property (e.g., like we have in new JMS). This means it can *only*
work if such classpath is provided and successfully loaded. Letting it continue
with simple warning message wil not accomplish anything, right?
> 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)
