One minor point: you don't need to use the "-Duima.suppress_annotator_logging" if you have the ability to alter the (embedding application's) logging configuration files; there you could specify, specifically (for each/every annotator class that is excessively logging), to set the logging level to OFF.
The -D parameter is for those situations where you can't reasonably alter the logging configuration files. -Marshall On 2/15/2017 10:46 AM, Marshall Schor wrote: > This is a 2 layer proposal; > > - one addresses configuring in embedded contexts, > > - the other specifically addresses Annotator writer's overly excessive > logging > without needing specific log configuration file options. > > The first one: suppose we change the UIMA logger to be a more-or-less empty > facade to slf4j. > > Then, if no back end is configured for slf4j, no logging happens (other than a > short one-time message saying that no logging will occur). This would be the > production mode. It could be configured in embedded applications to pick up > what the embedded application was using. > > For new users, the out-of-the-box experience would include using the binary > distribution of UIMA, which would include the JARs for log4j 2 back end, by > default put into the classpath for apps, so they would get logging. > > For Eclipse UIMA runtime plugin users, that would be configured to include > some > backend which logged to the Eclipse log. > > ----------------- > > For the 2nd, to address Annotator writers' mistakes in having too much > logging, > we could have an additional JVM argument for UIMA, something like > "-Dsuppress_annotator_logging", which would change just the UIMA logger used > by > annotators (via uima_context.getUimaLogger()) to bypass logging. > > WDYT? > > -Marshall > > On 2/15/2017 9:37 AM, Marshall Schor 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? >> >> -Marshall >> >> >> >> On 2/15/2017 8:05 AM, Joern Kottmann wrote: >>> Right, in your example you don't want to have logging on by default on a >>> high level like INFO. >>> You would probably want to see error or warning log messages. >>> >>> Anyway back to my case. We should still make sure that users who just get >>> started see the logs by default. >>> The eclipse runner plugin could always output logs to the console or maybe >>> even have a tab to configure it. >>> >>> If we have some runner command for an AE or AAE that could make sure logs >>> are printed to the console people who do more serious applications should >>> invest time to configure the logging like they need it if the default is >>> not sufficient. >>> >>> Jörn >>> >>> On Tue, Feb 14, 2017 at 5:12 PM, Thilo Goetz <[email protected]> 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 >>>>>> >
