Matt, +1 [non-binding] for the idea to move the Mongo dependencies into that bundle. I think it will likely need the NAR dependency on nifi-standard-services-api in order to provide a link to the SSL Context Service. Is that ticket / PR worthy as a one-off in the short term? No doubt the Extension Registry will be a powerful capability.
Also, +2 for the greeting, though Bryan may choose to put the "y" first. :-) Thanks, Brian On Mon, Mar 26, 2018 at 5:13 PM Matt Burgess <[email protected]> wrote: > Bri/yan, > > IMO I think we'd be better off with moving the > nifi-mongodb-client-service-api and nifi-mongodb-services bundles into > the nifi-mongodb-bundle. That's something I missed while reviewing the > PR that put them in standard services. I don't see a direct dependency > on nifi-standard-services, and if the nifi-mongodb-client-service-api > needs the nifi-standard-services-api as a dependency, it can make it a > NAR dependency. > > We might want to visit this as a much broader case, since I believe we > could run into this with other services APIs (Elasticsearch, HBase, > etc.)? Certainly when the Extension Registry becomes a thing, we might > not want "external" service APIs to be part of > nifi-standard-services-api. > > Regards, > Matt > > > On Mon, Mar 26, 2018 at 5:03 PM, Brian Ghigiarelli <[email protected]> > wrote: > > Thanks, Bryan! Sure enough, we have nifi-standard-services-api-nar as a > > parent to use the standard SSLContextService. Sounds like upgrading the > > mongo-java-driver for the base build is the way to go for us. > > > > Thanks again, > > Brian > > On Mon, Mar 26, 2018 at 15:29 Bryan Bende <[email protected]> wrote: > > > >> 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 <[email protected] > > > >> 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 > >> >
