Logging in Tika

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Logging in Tika

Jukka Zitting
Hi,

Opinions on how to handle logging in Tika? This question can be split
in three parts:

1) Logging in tika-core. Currently only the MimeTypesReader class
contains logging statements (commons-logging) in tika-core. It would
be feasible to even avoid all logging in tika-core.

2) Logging in tika-parsers. This is the trickiest part as different
parser libraries have different logging dependencies. I'm inclined to
push the problem to downstream projects like tika-app and leave the
logging dependencies as-is in tika-parsers. To keep things simple I'd
like to avoid any logging by the Parser adapter classes.

3) Logging in tika-app. A good question. As a standalone runnable jar
application I'd simply force all logging through something like log4j
and even handle all logging configuration through simple command line
arguments (--verbose, --debug) to TikaCLI. However, since tika-app is
now also an OSGi bundle, we might look at using things like the OSGi
log service. Not sure how well these two approaches work together, so
perhaps we should rather create a separate tika-osgi bundle for that?

BR,

Jukka Zitting
Reply | Threaded
Open this post in threaded view
|

Re: Logging in Tika

robert burrell donkin-2
On Sat, May 23, 2009 at 8:16 AM, Jukka Zitting <[hidden email]> wrote:
> Hi,
>
> Opinions on how to handle logging in Tika? This question can be split
> in three parts:
>
> 1) Logging in tika-core. Currently only the MimeTypesReader class
> contains logging statements (commons-logging) in tika-core. It would
> be feasible to even avoid all logging in tika-core.

+1

> 2) Logging in tika-parsers. This is the trickiest part as different
> parser libraries have different logging dependencies. I'm inclined to
> push the problem to downstream projects like tika-app and leave the
> logging dependencies as-is in tika-parsers. To keep things simple I'd
> like to avoid any logging by the Parser adapter classes.

+1

> 3) Logging in tika-app. A good question. As a standalone runnable jar
> application I'd simply force all logging through something like log4j
> and even handle all logging configuration through simple command line
> arguments (--verbose, --debug) to TikaCLI. However, since tika-app is
> now also an OSGi bundle, we might look at using things like the OSGi
> log service. Not sure how well these two approaches work together, so
> perhaps we should rather create a separate tika-osgi bundle for that?

+1 to separate OSGi bundle

+1 to using CLI

- robert
Reply | Threaded
Open this post in threaded view
|

Re: Logging in Tika

Jeremias Maerki-2
In reply to this post by Jukka Zitting
From my OSGi experience: when using Pax Logging (from OPS4J) logging in
an OSGi environment, logging is really something you don't have to
concern yourself too much with anymore. Use Log4J, Java logging, JCL,
SLF4J or whatever, it doesn't matter. The various adapters handle the
differences for you and you configure one logging system of your choice.
You should simply choose a logging API that you like for the non-OSGi
case if you need one. The rest inside OSGi is really trivial. No need to
create a dependency on the basic OSGi logging service from the spec.
That's one of the really nice aspects of OSGi.

OSGi is more of an issue when it comes to plug-in handling/detection.
The JAR service provider interface mechanism (META-INF/services) doesn't
work in OSGi, for example. An abstraction for looking up plug-ins might
be required, because you might have to handle both the OSGi and the
normal Java case. But that's for another thread. I'm likely to have a
few good pointers/ideas, maybe even code to deal with that in the next
couple of weeks. I have to solve that for a couple of libraries I plan
to use in my application.

On 23.05.2009 09:16:18 Jukka Zitting wrote:

> Hi,
>
> Opinions on how to handle logging in Tika? This question can be split
> in three parts:
>
> 1) Logging in tika-core. Currently only the MimeTypesReader class
> contains logging statements (commons-logging) in tika-core. It would
> be feasible to even avoid all logging in tika-core.
>
> 2) Logging in tika-parsers. This is the trickiest part as different
> parser libraries have different logging dependencies. I'm inclined to
> push the problem to downstream projects like tika-app and leave the
> logging dependencies as-is in tika-parsers. To keep things simple I'd
> like to avoid any logging by the Parser adapter classes.
>
> 3) Logging in tika-app. A good question. As a standalone runnable jar
> application I'd simply force all logging through something like log4j
> and even handle all logging configuration through simple command line
> arguments (--verbose, --debug) to TikaCLI. However, since tika-app is
> now also an OSGi bundle, we might look at using things like the OSGi
> log service. Not sure how well these two approaches work together, so
> perhaps we should rather create a separate tika-osgi bundle for that?
>
> BR,
>
> Jukka Zitting




Jeremias Maerki