You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by Konstantin Gribov <gr...@gmail.com> on 2017/03/21 18:26:03 UTC
Logging unification (TIKA-2245)
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
Re: Logging unification (TIKA-2245)
Posted by Konstantin Gribov <gr...@gmail.com>.
Thanks, Chris.
I've found some classes which slipped out of my grasp, I'll update them
soon (tomorrow, I guess, since it's almost 3:30 AM here).
Also, there's some log4j logging level jugging in some tests (e. g. in
PDFParserTest). Test dependency on log4j doesn't bother me as library deps
do but I'm going to factor it out to some util class in future.
вт, 21 мар. 2017 г. в 21:28, Mattmann, Chris A (3010) <
chris.a.mattmann@jpl.nasa.gov>:
> Great work Konstantin!
>
> Sent from my iPhone
>
> > On Mar 21, 2017, at 11:26 AM, Konstantin Gribov <gr...@gmail.com>
> 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
>
--
Best regards,
Konstantin Gribov
Re: Logging unification (TIKA-2245)
Posted by "Mattmann, Chris A (3010)" <ch...@jpl.nasa.gov>.
Great work Konstantin!
Sent from my iPhone
> On Mar 21, 2017, at 11:26 AM, Konstantin Gribov <gr...@gmail.com> 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