Hi Konstantin,
I didn't recognize the ramifications of this when working on
TIKA-3842. I'm sorry for this breaking change.
I'm personally hesitant to downgrade the main branch given that
2.5.0 has been out for a bit more than a month, and now we have 2.6.0.
This could be further reason to go back to managing two branches [0].
One could be a bug fix branch 2.7.x (with reverted slf4, requiring
only Java 8), and the other 2.8.x or maybe even 3.0.0 could be the
main branch (with the updated slf4j (as it currently is) and Java 11)?
I personally don't have any breaking plans for Tika 3.x[1]. It would
not be the heavy lift for users wrt metadata and new modules that 2.x
was. I _think_ most projects I'm keeping track of now are waiting for
major version changes before requiring Java 11.
What do you all think?
Best,
Tim
[0] https://issues.apache.org/jira/browse/TIKA-3735
[1] Except that I'd really like to clean up serialization from
tika-config.xml so that all components use the newer format. However,
we can maintain back compat without a problem until 4.x if we do
choose to go to 3.x soonish.
On Mon, Nov 7, 2022 at 6:54 PM Konstantin Gribov <[email protected]> wrote:
>
> Hi, folks.
>
> Sorry, I totally missed the moment when TIKA- 3842 [1] (update slf4j to
> 2.0.x) was discussed and merged.
>
> *TL;DR: **slf4j-api *update from 1.7.x to 2.0.x in *tika-core *2.5.0 requires
> downstream library users to update logging backend. *Tika Server* & *Tika
> Python* not affected. In most cases logging libraries have newer compatible
> versions except *slf4j-jboss-logmanager*. Downgrading *slf4j-api* may work
> but is potentially fragile. */TL;DR*
>
> It was **a breaking API change** for the *tika-core* and dependent packages
> like *tika-parser-*-module*, *tika-parsers-standard-package*.
>
> Good news:
> * users of the *tika-server* and *tika-python* should not be affected at
> all;
> * users with *log4j2* as a logging backend could replace *log4j-slf4j-impl*
> with *log4j-slf4j2-impl*;
> * users with *logback-classic* 1.2.x could update to *logback-classic*
> 1.4.x;
> * users with *log4j* 1.2.x (which is EOL since 2015 and has security
> vulnerabilities IIRC) could update to *slf4j-reload4j* 2.0.x;
>
> Users with *slf4j-jboss-logmanager* are currently out of luck and have to
> wait for a new release [2].
>
> I'm not sure if we should rollback *slf4j* to 1.7.36 or keep going as it's
> now and just document that 2.5.0 had a breaking change in the API.
>
> For example * Spring Boot* will make such a change on 2.x to 3.0
> transition, *Quarkus* will likely follow a similar path since they blocked
> bumping *slf4j* from 1.7.36 to 2.0.x.
>
> Downgrading *slf4j-api* *seems* to work in a simple case but all the calls
> to the loggers have to be reviewed to at least be sure that there's no
> calls to fluent logging API introduced in *slf4j-api* 2.0. More in depth
> investigation is required to have more confidence that such a setup would
> work flawlessly.
>
> To downgrade *slf4j-api* one could add following block to *pom.xml* for
> *Apache
> Maven* builds:
>
> ```
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <version>1.7.36</version>
> </dependency>
> </dependencies>
> </dependencyManagement>
> ```
>
> Similar with Gradle:
>
> ```
> dependencies {
> constraints {
> // api or implementations depends on usage, for java-library prefer api
> api("org.slf4j:slf4j-api") {
> version { strictly("1.7.36") } // or strictly("[1.7,1.8)") for
> dynamic version
> }
> }
> }
> ```
>
> [1]: https://issues.apache.org/jira/browse/TIKA-3842
> [2]: https://issues.redhat.com/browse/JBLOGGING-165
>
> --
> Best regards,
> Konstantin Gribov.
