Great work Konstantin!

Sent from my iPhone

> On Mar 21, 2017, at 11:26 AM, Konstantin Gribov <[email protected]> wrote:
> 
> Hi, folks.
> 
> TL;DR slf4j-api with log4j 1.2 backend as primary logging for Tika, almost
> in master, tika-core still use JUL. 2.x patch comming soon.
> 
> I've pushed [1] a branch with logging unification across all Tika classes
> and deps. I'm planning to do same thing for 2.x branch.
> 
> All classes (except tika-core ones) use private static final
> org.slf4j.Logger with called LOG for all logging activity with almost no
> exceptions: somewhere it could be protected instead of private.
> 
> All library jars (except tika-core) depend on slf4j-api directly or through
> other Tika libs.
> 
> All standalone jars use slf4j-log4j12 (Apache Log4j 1.2 backend) alongside
> with JUL and JCL (commons-logging) bridges which forward all logging to
> slf4j backend.
> 
> Tests are usually use slf4j-log4j backend, but tika-bundle integration test
> has to use another backend (slf4j-simple) to avoid non-triial OSGi
> classloading issue.
> 
> For ones who is interested in OSGi tika-bundle, it imports non-optional
> org.slf4j, org.slf4j.event, org.slf4j.helpers and org.slf4j.spi (all these
> are exported by slf4j-api bundle).
> 
> Also, dynamic import for org.slf4j.impl, org.slf4j.bridge (for
> jul-to-slf4j), org.apache.commons.logging (for jcl-over-slf4j) and
> org.apache.log4j are added. They are required for ForkParser to work in
> OSGi environment since it sends classes from bundle class loader and
> logging impl classes are required for it to work.
> 
> Most challenging part was to make ForkParser work in OSGi BundleIT test
> which prevented me from pushin these pathces back in January.
> 
> Fellow committers, please take a look into published patchset [1] to review
> it before I merge. Some changes are related to patchset but not to logging
> refactoring itself and I've decided to publish them with separate commits
> on same branch. It shouldn't break master but could prevent currently
> unmerged PRs from merging but it's lesser evil than current situation with
> logging. I should update wiki page about logging [2] after merge, of course.
> 
> [1]:
> https://github.com/apache/tika/compare/a9145d85afb6db5f99df70d6634caf9315ce7346...logging-refactored
> [2]: https://wiki.apache.org/tika/Logging
> 
> -- 
> 
> Best regards,
> Konstantin Gribov

Reply via email to