nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Bende <bbe...@gmail.com>
Subject Re: Custom NAR Class Loader Issue
Date Fri, 16 Mar 2018 19:57:16 GMT
This should be better going forward once the 1.6.0 release is out.

https://issues.apache.org/jira/browse/NIFI-4936

On Fri, Mar 16, 2018 at 3:49 PM, Otto Fowler <ottobackwards@gmail.com> wrote:
> This is also a problem for new AWS processors, say if you use a newer aws
> java sdk core in a dependency but also have to depend on the nifi-aws-nar.
>
>
> On March 2, 2018 at 13:40:21, Bryan Bende (bbende@gmail.com) wrote:
>
> Doug,
>
> I think the only solution is what you proposed about fixing the
> nifi-gcp-bundle...
>
> Basically, if a NAR needs a different version of a dependency that is
> already declared in the root pom's dependencyManagement, then the
> bundle's pom needs it own dependencyManagement to force it back to the
> specific version for the bundle.
>
> Ultimately it would be nice to re-evaluate our use of
> dependencyManagement in the root pom, because I don't think we should
> be forcing the version of so many things. Guava is a perfect example
> where we shouldn't be forcing all NARs to use a specific version of
> Guava, that defeats the whole purpose of NARs.
>
> There are other cases though where it does make sense because there is
> code in nifi/nifi-commons that we would likely want to keep in sync
> with the NARs that use the code.
>
> -Bryan
>
> On Fri, Mar 2, 2018 at 1:27 PM, Douglas Willcocks
> <douglas.willcocks@artefact.com> wrote:
>> Hi all,
>>
>> I'm encountering a JAR version dependency issue when developing a custom
>> Processor that uses the GCPCredentialsService in Nifi 1.5.0.
>>
>> 1) The nifi-gcp-bundle distributed with Nifi 1.5.0 (which contains
>> GCPCredentialsService) is packaged with dependencies on:
>>
>> - com.google.cloud:google-cloud:0.8.0
>> - com.google.auth:google-auth-library-oauth2-http:0.6.0
>>
>> Which both transitively depend on com.google.guava:guava:19.0, except the
>> root-level pom.xml for Nifi (here
>> <https://github.com/apache/nifi/blob/master/pom.xml>) explicitly pins the
>> guava version to 18.0.
>>
>> 2) The custom Processor I am building also depends on
>> com.google.cloud:google-cloud:0.8.0, but actually uses methods from this
>> library that depend on features added in com.google.guava:guava:19.0.
>>
>> 3) In order to make the GCPCredentialsService available inside my
>> Processor
>> NAR, I have added the nifi-gcp-services-api-nar as a parent.
>>
>> 4) The implementation of NarClassLoader always starts the search for
>> classes in the parent, which means that when my processor looks for
>> com.google.guava class definitions, the com.google.guava:guava:18.0 JAR
>> packaged with the nifi-gcp-services-api-nar is always found first,
>> resulting in a java.lang.NoSuchMethodError exception in my Processor's
>> execution.
>>
>> I'm not sure what the best solution is – I guess I could create my own
>> version of the nifi-gcp-bundle that has the correct pom.xml file to force
>> the use of guava:19.0, but that seems a bit overkill for a change that is
>> essentially 5 lines of XML in a POM file.
>>
>> Any suggestions or thoughts?
>>
>> Thanks!
>> Douglas
>> --
>>
>> Douglas Willcocks
>> VP France, Data Science & Engineering
>>
>> 19 Rue Richer, 75009 Paris, France
>> M: +33 6 80 37 60 72
>> E: douglas.willcocks@artefact.com
>>
>> W: http://www.artefact.com/
>>
>> --
>> This email and any attachments contains privileged and confidential
>> information intended only for the use of the addressee(s). If you are not
>> an intended recipient of this email, you are hereby notified that any
>> dissemination, copying or use of information is strictly prohibited. If
>> you
>> received this email in error or without authorization, please delete the
>> email from your system and notify us immediately by sending us an email.
>> If
>> you need any further assistance, please send a message to
>> hello@artefact.com
>> .

Mime
View raw message