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.
