nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Burgess <mattyb...@apache.org>
Subject Re: Class Loading Conflicts - Different JAR Versions
Date Mon, 26 Mar 2018 22:59:21 GMT
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 to put it
there for a reason. If not, let's do it, if you're willing to submit
the contribution I/we'd be more than happy to review/incorporate it :)

Regards,
Matt


On Mon, Mar 26, 2018 at 6:20 PM, Brian Ghigiarelli <brianghig@gmail.com> wrote:
> 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 <mattyb149@apache.org> 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 <brianghig@gmail.com>
>> 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 <bbende@gmail.com> 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 <brianghig@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
>> >>
>>

Mime
View raw message