Feb 14, 2017 5:44:39 PM WhitespaceTokenizer process
INFO: "Whitespace tokenizer starts processing"
Feb 14, 2017 5:44:39 PM WhitespaceTokenizer process
INFO: "Whitespace tokenizer finished processing"
Feb 14, 2017 5:44:39 PM WhitespaceTokenizer process
INFO: "Whitespace tokenizer starts processing"
Feb 14, 2017 5:44:39 PM WhitespaceTokenizer process
INFO: "Whitespace tokenizer finished processing"
Feb 14, 2017 5:44:39 PM WhitespaceTokenizer process
INFO: "Whitespace tokenizer starts processing"
Feb 14, 2017 5:44:39 PM WhitespaceTokenizer process
INFO: "Whitespace tokenizer finished processing"
On 14/02/2017 17:30, Marshall Schor wrote:
can you post some log output that occurs per document that is configured (by
default) to be "on"?
-Marshall
On 2/14/2017 11:12 AM, Thilo Goetz wrote:
On 14/02/2017 15:29, Joern Kottmann wrote:
A common case we will have is a user who is ignorant about the logging and
doesn't care about it, for him - out of the box - the log messages should
be printed to the console.
I disagree. UIMA is a library that is usually embedded in another application.
By default, it should not do any logging at all. Please think about people who
use UIMA in contexts where we don't have control over the startup of the VM,
such as Hadoop or Spark. The fact that I can't turn off logging without
providing some sort of config file for the VM at startup time is a major pain
in the neck, at least for me. It is not just annoying, it is a real issue when
you process thousands of documents per second and UIMA insists on logging
several lines for each of them. Please make it stop.
--Thilo
Is that possible with sl4j?
Jörn
On Tue, Feb 14, 2017 at 12:14 PM, Richard Eckart de Castilho <[email protected]
wrote:
On 06.02.2017, at 21:39, Marshall Schor <[email protected]> wrote:
now considering not using logback except via eclipse plugin dependency,
to avoid
license reciprocity issue.
For normal binary packaging, would use slf4j + some backend, perhaps
log4j 2.
These would be "excluded" for the OSGi packaging.
UIMA as a library should not have dependencies on a particular logging
backend.
I guess when you talk about "normal binary packaging" you mean the binary
release
package that we do, right?
So these instead of "excluding" a logging backend for OSGi, I think it
would rather
be "including" a logging backend only for OSGi and the binary packaging
but not
having it in any other way as a dependency in any POM (except maybe as a
test dependency).
-- Richard
