Re: Class Loading Conflicts - Different JAR Versions

Mike, Here is a PR that should setup the ES stuff appropriately: https://github.com/apache/nifi/pull/2586 If we merge this for 1.7 then we should mention something in the migration notes, not that there is anything someone needs to do, but just for knowledge in case someone tries to do some

Re: Class Loading Conflicts - Different JAR Versions

You can look at the aws nar for a sample of what I think Brian means. On March 27, 2018 at 07:31:54, Mike Thomsen (mikerthom...@gmail.com) wrote: Brian, So... nifi-foo-service-impl-nar + nifi-foo-processors-nar ---depend on---> nifi-foo-service-api-nar ---depends on--->

Re: Class Loading Conflicts - Different JAR Versions

Brian, So... nifi-foo-service-impl-nar + nifi-foo-processors-nar ---depend on---> nifi-foo-service-api-nar ---depends on---> nifi-standard-services-api-nar That's what I should look for in the ES NARs? On Mon, Mar 26, 2018 at 10:31 PM, Bryan Bende wrote: > Also, regarding

Re: Class Loading Conflicts - Different JAR Versions

Also, regarding the elastic search issue Mike mentioned… Usually when a processor can’t select the controller service at runtime it is because theres an issue with the way the dependencies are setup between NARs. There should generally be dependency paths like the following…

Re: Class Loading Conflicts - Different JAR Versions

I’m a +1 for moving the Mongo stuff out of standard services. Controller service APIs should always be broken out into their own NAR, but the processors and implementation can usually be bundled together. So something like the following would work: nifi-mongo-bundle -

Re: Class Loading Conflicts - Different JAR Versions

I was just following a convention at the time. So unless something breaks because of the move, I don't see any reason why it would be an issue to move it. In fact, with NIFI-4325 the only reason I put the new ElasticSearch service/api in the standard-services segment of the code base was I ran

Re: Class Loading Conflicts - Different JAR Versions

Brian (this one's all you ;), I think that PR is quite welcome in my opinion, but I'd like to get Mike Thomsen's and others' opinions on the subject too, I think Mike wrote the original service (or at the least is very knowledgable about Mongo and NiFi), he might have run into issues that led him

Re: Class Loading Conflicts - Different JAR Versions

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

Re: Class Loading Conflicts - Different JAR Versions

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,

Re: Class Loading Conflicts - Different JAR Versions

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 wrote: >

Re: Class Loading Conflicts - Different JAR Versions

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

Class Loading Conflicts - Different JAR Versions

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