FWD » Core Development » Runtime Infrastructure

As of trunk rev 15182, you can see the following.

1. During FWD build, there is this:

[ant:javac] /home/ges/projects/trunk/src/org/slf4j/impl/StaticLoggerBinder.java:73: warning: [deprecation] LoggerFactoryBinder in org.slf4j.spi has been deprecated
[ant:javac] implements LoggerFactoryBinder
[ant:javac]            ^

Can we eliminate (not just ignore) this deprecated warning?

2. During conversion, the following is emitted:

     [java] SLF4J(W): No SLF4J providers were found.
     [java] SLF4J(W): Defaulting to no-operation (NOP) logger implementation
     [java] SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.
     [java] SLF4J(W): Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.
     [java] SLF4J(W): Ignoring binding found at [jar:file:/home/ges/projects/trunk/build/lib/fwd-slf4j.jar!/org/slf4j/impl/StaticLoggerBinder.class]
     [java] SLF4J(W): See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.

I really don't want ANY SLF4J output mixed into our conversion output. I don't recall what pulls this in.

3. At server startup, on the console in which server.sh is executed we see this:

SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J(W): Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.
SLF4J(W): Ignoring binding found at [jar:file:/home/ges/projects/samples/h_gui/deploy/lib/fwd-slf4j.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J(W): See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.
MLog initialization issue: slf4j found no binding or threatened to use its (dangerously silent) NOPLogger. We consider the slf4j library not found.
May 01, 2024 7:45:52 AM com.mchange.v2.log.MLog 
INFO: MLog clients using java 1.4+ standard logging.
... (and more, including lots ofc3p0 nonsense)

This MLog crap is part of mchange which is used by c3p0. It should NOT be crudding up our console with log entries. If these entries are important, then we should configure c3p0 to log properly to our server log. And I'd like to eliminate these SLF4J notices.

Someone did something... wasn't me and this should have never appeared.

This warnings Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier. indicates org.slf4j:slf4j-api is version > 1.7.x and trunk has 1.7.36 in build.gradle so this shouldn't have happened.

Let me babysit it... I mean debug the transitive dependencies.

8708a r15183 based on trunk r15182: remove the transitive dependency of slf4j-api:2.0.10 from tika-core.

Diff of the change:

=== modified file 'build.gradle'
--- build.gradle    2024-04-25 09:32:14 +0000
+++ build.gradle    2024-05-01 14:03:32 +0000
@@ -141,6 +141,7 @@
 **                  to version 2.9.x and only including the required modules.
 ** 065 GBB 20240419 ghost4j removed, replaced by pdfbox.
 ** 066 CA  20240415 Upgraded to the latest FWD-H2 1.46.
+** 067 GBB 20240501 slf4j-api v2 removed from transitive dependencies of tika-core.
 */

 /*
@@ -592,7 +593,9 @@
     fwdClient group: 'javax.json', name: 'javax.json-api', version: '1.1.4'
     fwdClient group: 'org.jsoup', name: 'jsoup', version: '1.14.3'
     fwdClient group: 'gettext', name: 'gettext.js', version: '1.2.0', ext: 'zip' // WARNING: this zip name is hardcoded in WebResourceHandler
-    fwdClient group: 'org.apache.tika', name: 'tika-core', version: '2.9.2'
+    fwdClient (group: 'org.apache.tika', name: 'tika-core', version: '2.9.2') {
+        exclude group: 'org.slf4j', module: 'slf4j-api'
+    }
     fwdClient group: 'org.apache.tika', name: 'tika-parser-text-module', version: '2.9.2'
     fwdClient group: 'org.apache.tika', name: 'tika-parser-html-module', version: '2.9.2'

Can we merge this soon, because it's too annoying?

We're sure that the tika parser code we are using doesn't require slf4j?

Greg Shah wrote:

We're sure that the tika parser code we are using doesn't require slf4j?

It uses a new version of slf4j api, how do we comply to both apis at the same time? It's either tika, or everything else. When java 17 is enabled, this will be updated.

If this breaks the tika code, then we can't merge it because we have a customer using it in real life.

If 6692a resolves this, then we may have to wait for it. We are literally trying to get Java 17 into trunk next week if possible.

What do you mean? Jetty is working on those systems.

Greg Shah wrote:

What do you mean? Jetty is working on those systems.

The logging is broken.

Another way to solve it now is to downgrade tika to 2.4.1.

Galya B wrote:

Greg Shah wrote:

What do you mean? Jetty is working on those systems.

The logging is broken.

Another way to solve it now is to downgrade tika to 2.4.1.

There are vulnerabilities in all the previous versions. We should stick to 2.9.x. I'll test if the older slf4j api doesn't break 2.9.x. If it works I suggest we keep the exclusion.

Hynek Cihlar wrote:

There are vulnerabilities in all the previous versions. We should stick to 2.9.x. I'll test if the older slf4j api doesn't break 2.9.x. If it works I suggest we keep the exclusion.

Tested, it looks OK.

Hynek Cihlar wrote:

Tested, it looks OK.

Did you find any slf4j message from tika in the client log?

Galya B wrote:

Hynek Cihlar wrote:

Tested, it looks OK.

Did you find any slf4j message from tika in the client log?

No. But I don't even know, where they use slf4j. I went through the (relevant) Tika classes and I didn't find any references to slf4j.