nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Bateman <r...@windofkeltia.com>
Subject Re: Pulling out hair over slf4j...
Date Mon, 08 May 2017 21:14:56 GMT
I understand that no NiFi JAR comes with /slf4j/, but expects the 
consuming build to provide it. That's the assumption I've been going on 
and it's why in my top-level /pom.xml/, I've specified [1.7.25] so that 
no quibbling over version can occur and I specify these JARs in the root 
/pom.xml/ so that no "renegade" submodule calls the dependency for its own.

The problem is that some version of slf4j-api-x.y.z.jar doesn't provide 
a MessageFormatter class containing an arrayFormat() method, right? 
Somehow, though, this impoverished version is the one bound to my code 
despite my marking every dependency with Andrew's exclusion statements?

There is nothing giving this away; in IntelliJ IDEA, under External 
Libraries in the Project pane, I see only 1.7.25 of these libraries, no 
additional versions. I wonder if I should see more versions if in fact 
that's what's going on?

I tried wiping /~/.m2/repository/org/slf4j/, after mvn clean compile of 
my project, I see all those versions have come back to 
/~/.m2/repository/org/slf4j/. So, at the root of my project, I created 
/hard-repository/, and stuffed it with the slf4j-relevant JARs arranged 
in their repository accoutrements (paths, files, everything), then added

    <repositories>
       <repository>
         <id>slf4j</id>
         <name>slf4j repo</name>
    <url>file://${project.build.directory}/hard-repository/maven_repo</url>
      </repository>
    </repositories>

...first, so that this dependency would be satisfied--not that this 
should be necessary. So, I took this back out as superfluous.

To me, this means that something else I'm linking has already 
hard-linked some version of slf4j-api older than (maybe 1.7.x--whenever 
MessageFormatter acquired this new method) which would prevent me from 
getting 1.7.25 and yet, IntelliJ's External Libraries list and, 
examining the module dependencies tab for each individual module I see 
only 1.7.25.

I am stumped. I guess I could attempt to link in the NiFi test framework 
in such a way as to be able to debug down into it better to watch fail. 
I've stepped down in using IDEA's decompiler, which I would think 
adequate, but I don't see exactly what's amiss.





On 05/08/2017 11:10 AM, Bryan Bende wrote:
> Ok thanks for all the info, I am not totally sure what is going, but I
> can tell you how the logging JARs are setup in NiFi and maybe that
> will shed some light on things...
>
> In the root pom for NiFi there is a dependencyManagement section that
> declares slf4j-api, jul-to-slf4j, log4j-over-slf4j, and jcl-over-slf4j
> all as provided dependencies to ensure no NARs actually bundle these
> since they will be provided directly in the lib directory and
> available to all NARs, this also forces them all to
> ${org.slf4j.version} which in master is 1.7.25:
>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>jcl-over-slf4j</artifactId>
>      <version>${org.slf4j.version}</version>
>      <scope>provided</scope>
> </dependency>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>log4j-over-slf4j</artifactId>
>      <version>${org.slf4j.version}</version>
>      <scope>provided</scope>
> </dependency>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>jul-to-slf4j</artifactId>
>      <version>${org.slf4j.version}</version>
>      <scope>provided</scope>
> </dependency>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>slf4j-api</artifactId>
>      <version>${org.slf4j.version}</version>
>      <scope>provided</scope>
> </dependency>
>
>
> Then the nifi-assembly pom.xml declares these using compile scope and
> puts them in the lib directory:
>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>jcl-over-slf4j</artifactId>
>      <scope>compile</scope>
> </dependency>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>jul-to-slf4j</artifactId>
>      <scope>compile</scope>
> </dependency>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>log4j-over-slf4j</artifactId>
>      <scope>compile</scope>
> </dependency>
> <dependency>
>      <groupId>org.slf4j</groupId>
>      <artifactId>slf4j-api</artifactId>
>      <scope>compile</scope>
> </dependency>
>
> Now for Unit tests, the root pom has a regular dependencies section
> that has slf4j-simple declared with test scope:
>
>      <dependency>
>          <groupId>org.slf4j</groupId>
>          <artifactId>slf4j-simple</artifactId>
>          <scope>test</scope>
>      </dependency>
>
> So every NAR that is with in the NiFi project will have slf4j-simples
> available for unit tests.
>
> Andrew Psaltis also mentions a good point about the different
> versions, I believe we just upgraded to 1.7.25 for the 1.2.0 release,
> but previous were on 1.7.12, but you should double check that.
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message