bbende commented on a change in pull request #4540: URL: https://github.com/apache/nifi/pull/4540#discussion_r496907835
########## File path: nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-resources/src/main/resources/conf/bootstrap.conf ########## @@ -66,6 +66,15 @@ java.arg.16=-Djavax.security.auth.useSubjectCredsOnly=true # Please see https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_adminserver_config for configuration options. java.arg.17=-Dzookeeper.admin.enableServer=false +# The following options configure a Java Agent to handle native library loading. +# It is needed when a custom jar (eg. JDBC driver) has been configured on a component in the flow and this custom jar depends on a native library +# and tries to load it by its absolute path (java.lang.System.load(String filename) method call). +# Use this Java Agent only if you get "Native Library ... already loaded in another classloader" errors otherwise! +#java.arg.18=-javaagent:./lib/aspectjweaver-${aspectj.version}.jar Review comment: Well it does have an effect... If the jars are in lib then they are on the classpath of every NAR, so if someone makes a custom NAR that bundles a different version of aspectj, then there will be two versions on the classpath, and there is nothing the NAR can do to avoid the one in lib. I would actually vote for option 3... create a new module like `nifi-nar-aspect-utils` or whatever we want to call it, and put the dependency there along with `LoadNativeLibAspect`, then `lib/aspectj` can contain `nifi-nar-aspect-utils` jar and the aspectj jars. Would that work? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
