On 2/15/2017 10:12 AM, Richard Eckart de Castilho wrote: >> On 15.02.2017, at 15:37, Marshall Schor <[email protected]> wrote: >> >> I'm hearing both: >> >> a) have UIMA not log anything unless it is "provided with" some logger back >> end. In other words, the core UIMA without a back end should run with no >> logging (and hopefully, no delays for logging calls). >> >> b) have UIMA in some new-user-getting-started configuration see logs by >> default. >> >> Is this correct? >> >> If so, it seems we need to have some way to package UIMA to have this >> user-getting-started configuration by default, which can be stripped out for >> case (a). Does this sound right? > I'm not sure I understand the problem. The UIMA logging framework > already now uses different kinds of backends. By default, the > JSR47Logger_impl backend is used (aka Java Utility Logging).
I think this is the problem, because this default is not dependent on an embedding context's logging setup. > > The Java Utility Logging that comes with the JRE has a default logging > configuration that prints certain levels to certain channels. This > is not something that UIMA invents, but something that JRE does. > > Now users have these options: > > 1) provide the JRE with a JSR47 configuration file via a system property > 2) configure JSR47 programmatically after program start > 3) switch UIMA to a different logging backend via a system property > and then again perform 1) or 2) if they are not happy with the > logging defaults of that backend > > Irrespective of what kind of backend UIMA uses, it will always come > with some defaults and users will have to do 1) or 2). > > We could drop all logging code from the framework entirely, but I > wouldn't like that because it would make it impossible to enable > (debug) logging through the proper mechanisms of the logging framework > being used. I don't think anyone is suggesting this :-) > > I think it is reasonable that UIMA includes logging and actually performs > logging on sensible logging levels including TRACE, DEBUG, INFO, ERROR, FATAL, > etc. If users are not happy with the defaults of the logging framework that > they > use, then they need to reconfigure it. I find it hard to imagine that it would > not be possible to change the logging framework settings when running Hadoop > jobs or when embedding UIMA in an application. I have little experience with > Hadoop in that respect, but in applications, I usually use log4j and I then > configure UIMA to also use the log4j backend. Following that I can happily > control the logging levels of my application and of UIMA (framework as well > as all components that log through the UIMA logging framework). The change to logging request sounds to me similar to other things UIMA does - in "protecting" an application where reasonable from user (e.g. annotator writers') mistakes. Here, the mistake is the annotator writer includes too much logging at the wrong level in their annotator code. What seems to be wanted is a way for UIMA to (in a "production mode"), turn off those logging statements in all annotator code. While this could be done by configuring specific loggers (those named the same as the annotator's class) to "OFF" level, when UIMA is embedded in other frameworks, this may be hard to do (I'm not sure why, but that's what I hear is being asserted) So, what's being requested is (in production mode) to have logging by annotator writers turned off (if they are using the UIMA loggers). Other logging by UIMA for errors, debugging, etc., would be left alone (because we assume UIMA logging is correctly done with respect to specifying levels, controlling verbosity, etc.). > Cheers, > > -- Richard
