On 14/02/2017 19:11, Marshall Schor wrote:
Thank you.
That message is (of course) being generated by the Whitespace Tokenizer
Annotator, not by UIMA itself.
That said, there seem to be a few ways to stop that message:
a) change the implementation of that Annotator to not output that message
I can do that for this specific annotator, but I also use annotators
that do the same thing, where I don't have access to the source code. So
that doesn't really help.
b) explicitly configure the log level to not log INFO messages (could be made
specific to the Whitespace Tokenizer Annotator, or general) I take it this kind
of configuration is hard to do when UIMA is, in turn, embedded into some other
framework.
c) implicitly configure the log level to not log INFO messages by default. I
think in fact this is the default? Perhaps the embedding application is setting
this to INFO?
Is modifying the Annotator so it doesn't log on every document a viable option
for you? Or is that just one example, and what you want is some way to
configure the logger to turn off logging, but without using the configuration
that's available with loggers at deploy time?
The latter. IMO, annotators shouldn't log anything, anyway. And the
framework should only log if it is provided with a logger by the
embedding application. I really think that I should not have to jump
through hoops if I don't want any log output. Am I the only one who
thinks that? It's fine if all you do is UIMA processing. However, when
UIMA is only a small part of a bigger whole, I should be able to
integrate it into whatever I'm running in. The logging needs to be
controlled by the main application, whether that's Hadoop, Spark, or
something I write myself. UIMA should not take it upon itself to log
anything when nobody is asking it to.
--Thilo
-Marshall
On 2/14/2017 11:45 AM, Thilo Goetz wrote:
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
