nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: Custom NAR Class Loader Issue
Date Fri, 16 Mar 2018 19:49:41 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message