Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2653#discussion_r187131152
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/cf/JMSConnectionFactoryProvider.java
---
@@ -159,13 +159,15 @@ public void enable(ConfigurationContext context)
throws InitializationException
if (logger.isInfoEnabled()) {
logger.info("Configuring " +
this.getClass().getSimpleName() + " for '"
+
context.getProperty(CONNECTION_FACTORY_IMPL).evaluateAttributeExpressions().getValue()
+ "' to be connected to '"
- + BROKER_URI + "'");
+ +
context.getProperty(BROKER_URI).evaluateAttributeExpressions().getValue() +
"'");
}
+
// will load user provided libraries/resources on the
classpath
-
Utils.addResourcesToClasspath(context.getProperty(CLIENT_LIB_DIR_PATH).evaluateAttributeExpressions().getValue());
+ final String clientLibPath =
context.getProperty(CLIENT_LIB_DIR_PATH).evaluateAttributeExpressions().getValue();
+ ClassLoader customClassLoader =
ClassLoaderUtils.getCustomClassLoader(clientLibPath,
this.getClass().getClassLoader(), null);
+
Thread.currentThread().setContextClassLoader(customClassLoader);
--- End diff --
The problem with this approach I think is that we're now creating the
ClassLoader and using it to create the connection factory. However, when we do
that, we would need to ensure that any access to the connection factory
instance also is performed using the ClassLoader. Since all calls into this
Controller Service could come from different threads, I think this is going to
cause a problem.
I think the typical pattern here is to update the property descriptor of
CLIENT_LIB_DIR_PATH to include .dynamicallyModifiesClassPath(true). In this
case, the framework will automatically handle creating the appropriate
ClassLoader for each instance of the controller service and will also ensure
that the appropriate ClassLoader is set when any method on this Controller
Service is invoked.
---
