getLogger Irritation with regular CLI

[M3ssman]

Issue description

Using recent version (1778b3) of dinglehopper complains because of OCR-D-Logger

dinglehopper 1300565-gt.xml 1300565.xml

=> 

21:17:33.416 CRITICAL root - getLogger was called before initLogging. Source of the call:
21:17:33.416 CRITICAL root -   File "/home/hartwig/Projekte/work/mlu/ulb/ulb-sachsen-anhalt-dinglehopper/qurator/dinglehopper/extracted_text.py", line 243, in get_first_textequiv
21:17:33.416 CRITICAL root -     log = getLogger("processor.OcrdDinglehopperEvaluate")

Even though all report-files are being generated, the output is somehow irritating.

Steps to reproduce the issue

1. call dinglehopper 1300565-gt.xml 1300565.xml (attached)

What's the expected result?

• No logging error or no logging at all if no OCR-D is around

Additional details

The Problem could be worked around if you use OCR-D's initLogging also within the context of the non-OCR-D-CLI, adding in cli.py something like this:

initLogging()
Config.progress = progress
process(gt, ocr, report_prefix, metrics=metrics, textequiv_level=textequiv_level)

Does dinglehopper want to stick with the OCR-D-Logger also in potential non-OCR-D-contexts? Further, it looks like dinglehopper is currently missing any dedicated logging-configuration, which couples it rather strong not only to the OCR-D-Logging-Logic, but also to it's configuration.

1300565-test.zip

[kba]

The Problem could be worked around if you use OCR-D's initLogging also within the context of the non-OCR-D-CLI, adding in cli.py something like this:

I'm open to reintroducing on-the-fly initLogging() and dropping the error messages, as they should really be debug messages, maybe discuss in OCR-D/core#621

which couples it rather strong not only to the OCR-D-Logging-Logic, but also to it's configuration.

But is that such a bad thing? Reusing the OCR-D logging framework gives configuration files and globally overrideable log levels. My point is that it would benefit all things OCR-D if we improved the versatility/usability of the logging framework.

[mikegerber]

Yes, this errror message bothered me too, last time I used the non-OCR-D CLI. I'll look into it

[M3ssman]

@kba Totally agree in the realms of OCR-D. But this time its all about dinglehopper's non-OCR-D-CLI.
To be honest, I wasn't even able to figure out where the log messages are going after all.

[mikegerber]

We now just call ocrd_utils' initLogging() in both the non-OCR-D CLIs dinglehopper and dinglehopper-extract to get this resolved!

[mikegerber]

To be honest, I wasn't even able to figure out where the log messages are going after all.

To stdout, it seems.