On 10/9/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: > On 10/8/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > >... We'd define a very simple Tika-specific logging interface, provide an > > implementation that logs to stderr, and allow client code to wrap any > > other logger as they see fit....
> A couple of thoughts: > 1) would this mess up logging that displays the class method?... Gotcha. We could require "this" to be included in the logging calls, to make sure we have the class name but this starts to get messy... > ...2) if you go this route, be sure to include an isLoggable(level).... Sure, not all logging libraries are efficient if you don't use this. > ...3) throw exceptions whenever possible instead of logging (small libs > should probably avoid logging altogether)... Not logging anything....why not, sounds like a good idea. I'm all for throwing exceptions when things go wrong, and using logging more for debugging and informational stuff. And Tika will probably stay easy to debug, as most tests (for now all of them) run in single-threaded mode with no rocket science stuff. I'd be ok with the idea of not doing any logging in Tika. As this is an important design decision, we might want to have a vote to make sure we're all on the same wavelength. What do people think? -Bertrand
