Brian, Is your custom processor using the MongoDBClientService provided by NiFI's standard services API? or does your NAR have a parent of nifi-standard-services-api-nar to use other services?
Looking at where the Mongo JARs are from a build of master... find work/nar/ -name *mongo-java*.jar work/nar//extensions/nifi-standard-services-api-nar-1.6.0-SNAPSHOT.nar-unpacked/META-INF/bundled-dependencies/mongo-java-driver-3.2.2.jar work/nar//extensions/nifi-mongodb-services-nar-1.6.0-SNAPSHOT.nar-unpacked/META-INF/bundled-dependencies/mongo-java-driver-3.2.2.jar work/nar//extensions/nifi-mongodb-nar-1.6.0-SNAPSHOT.nar-unpacked/META-INF/bundled-dependencies/mongo-java-driver-3.2.2.jar I think the issue is that if your NAR has nifi-standard-services-api-nar as a parent NAR (which it probably does to use SSLContext service, or any other standard service) then you are getting mongo-java-driver-3.2.2 from MongoDBClientService since we have parent first class loading. Given this situation I think there are only two options... not having nifi-standard-services-api-nar as a parent (which stops you from using all standard services), or upgrading the version of mongo-java-driver used by MongoDBClientService. -Bryan On Mon, Mar 26, 2018 at 3:16 PM, Brian Ghigiarelli <briang...@gmail.com> wrote: > Hey all, > > Is there a means of troubleshooting a custom NAR that seems to be having > runtime conflicts by picking up an older JAR that's provided by the NiFi > standard bundle? > > In this particular case, I'm using some custom processors that are built > against NiFi 1.4.0 and have a dependency on MongoDB 3.6.3. At runtime, I'm > seeing the processor use classes from MongoDB 3.2.2 that's provided by > NiFi. Both NiFi and the custom NAR compile successfully on their own, but > using the custom NAR in NiFi causes NoSuchMethodError's due to a new method > only available in MongoDB 3.4+. > > Thanks, > Brian
