On Fri, 7 Mar 2014, Konstantin Gribov wrote:
Tika-core is quite pure (uses only java.util.logging) but tika-parsers uses commons-logging 1.1.1 (through pdfbox), slf4j-api 1.5.6 (through netcdf) and log4j 1.2.14 (through slf4j-log4j as test scope dependency). Also some parsers (like pdfbox) logs just to stdout/stderr.
I think part of the issue is that many of the libraries that Tika depends on have their own chosen logging library / setup. IIRC, the Tika parsers often log in a similar manner to the underlying library they use.
That's not to say that we can't tidy things up a bit, but it does restrict how much we can do where log messages come from underlying libraries
It's confusing. Tika-core use only JUL.
Tika-Core ideally shouldn't have any external depdencies, so I'm not sure what else it can use while maintaining that?
Tika-parsers use JCL and log4j (in tests) and depends on slf4j-api. Tika-app use JCL, configures log4j in runtime (to change verbosity level) and depends on slf4j-log4j12. Tika-server use only JCL but depends on slj4j-api 1.7.5 (through cxf).
Potentially some of these could be rationalised, though maybe the best we can hope for is to ensure they only use whatever their underlying dependencies use
By the way, I think we also should update edu.ucar:netcdf to 4.2.20 that depends on newer slf4j-api 1.6.1.
Can you open a jira for that upgrade? If you can also try it locally, and report on the jira if all the unit tests still pass, that'd be a help!
Thanks Nick
