You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2017/01/24 20:48:12 UTC
uima v3 logging
Looking into what to do for UIMA v3 logging. Some things I'm learning:
- When UIMA is used as part of bigger applications, those apps frequently
specify a particular logging implementation and strategy, to which the
information logged by UIMA should conform.
- Java 8 lambda allows deferring expensive computation of logged values
-- a more compact way than guarding each log statement with an if
(log-xxx-level-is-enabled...)
- SLF4j seems to be the best logging "facade". It allows switching of actual
logging implementation at deploy time
- logback (an implementation) is the next generation beyond log4j
- UIMA implements its own facade, that can be mapped to 3 impls:
-- log4j
-- native-java-logger (called JSR47logger)
-- a non-framework, only minimally configurable, not documented, and probably
not-used implementation that writes to some standard output places
- uimaFIT has an internal (package) class that extends the base UIMA APIs with
a few of the SLF4j apis.
- New logging facilities available via SLF4j and supported by logback include
-- MDC (Mapped Diagnostic Contexts), having 1 instance per thread
-- Markers (discussed here:
http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback
My first impression of all this for UIMA v3 is 3 main ideas:
1) keep the current UIMA logging facade and framework, for backwards compatibility.
2) add the SLF4J facade (which includes support for Java 8 lambdas as
arguments), and instructions on how to configure logback and other implementations.
3) add some standard MDC and Markers - these need to be architected for "common"
use cases for UIMA logging, in ways that won't conflict with users.
Other views/opinions?
-Marshall
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
I think that (some) modern logging frameworks have this.
log4j and logback (and maybe others) have a "OFF" level.
Not sure about the API call part. Internet search seems to indicate several ways
to do this, with various caveats.
-Marshall
On 1/25/2017 10:13 AM, Thilo Goetz wrote:
> What would be really nice is a simple way to turn off all logging, preferably
> via an API call.
>
>
> On 25/01/2017 15:41, Marshall Schor wrote:
>> Thoughts on possible MDC (Mapped Diagnostic Contexts) for core UIMA:
>> * the id of the CAS (if there is a cas in the context at the point of
>> logging)
>> * the id of the pipeline (currently missing but could be architected into V3)
>> ** within the pipeline, the key name of the component (if there is a cas in
>> the context at the point of logging)
>> ** for UIMA-as/service: the client id information (which may include
>> pipeline id, "session id", etc.)
>>
>> I'm guessing that more standard things like the caller's class, the thread
>> id/name, might be generally available.
>>
>> -Marshall
>>
>>
>
>
Re: uima v3 logging
Posted by Thilo Goetz <tw...@gmx.de>.
What would be really nice is a simple way to turn off all logging,
preferably via an API call.
On 25/01/2017 15:41, Marshall Schor wrote:
> Thoughts on possible MDC (Mapped Diagnostic Contexts) for core UIMA:
> * the id of the CAS (if there is a cas in the context at the point of logging)
> * the id of the pipeline (currently missing but could be architected into V3)
> ** within the pipeline, the key name of the component (if there is a cas in
> the context at the point of logging)
> ** for UIMA-as/service: the client id information (which may include
> pipeline id, "session id", etc.)
>
> I'm guessing that more standard things like the caller's class, the thread
> id/name, might be generally available.
>
> -Marshall
>
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
Thoughts on possible MDC (Mapped Diagnostic Contexts) for core UIMA:
* the id of the CAS (if there is a cas in the context at the point of logging)
* the id of the pipeline (currently missing but could be architected into V3)
** within the pipeline, the key name of the component (if there is a cas in
the context at the point of logging)
** for UIMA-as/service: the client id information (which may include
pipeline id, "session id", etc.)
I'm guessing that more standard things like the caller's class, the thread
id/name, might be generally available.
-Marshall
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
On 1/29/2017 10:47 AM, Richard Eckart de Castilho wrote:
> On 24.01.2017, at 21:48, Marshall Schor <ms...@schor.com> wrote:
>> 1) keep the current UIMA logging facade and framework, for backwards compatibility.
> uimaFIT adds a getLogger() method to its base-classes for reader and engines because
> getting the logger via the context is just an extra step (getContext().getLogger().error(...) vs
> getLogger().error(...)).
I like adding this to the uima component base classes; thanks for the suggestion.
>
> It could be considered adding logging methods directly to the UIMA component base-classes, such
> that one simply would call "error(...)"? Or introducing a short getter method (log().error(...)))?
Not so sure about this, mainly because the log4j APIs are large. For example,
from the log4j-api, to get a logger, there are (excluding deprecated)
- 4 APIs for getting a formatterLogger (one that lets you use format strings)
- 9 APIs for getting a logger
and once you have a logger, there are methods for all the levels:
- debug, error, fatal, info, trace, warn
- plus log itself,
- plus "flow-event" calls: throwing, catching, traceEntry, traceExit
and for each of the main kinds (e.g. warn, info, etc.) there are 23 varieties,
(excluding the ones with 1, 2, ... 9 parameters).
If someone can figure out a good way to subset this down to the "essential set"
mostly used, maybe we could do that.
-Marshall
> Cheers,
>
> -- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
I see log4j -2 has renamed MDC ( and NDC) as "ThreadContext".
https://logging.apache.org/log4j/2.x/manual/thread-context.html
I think this is slightly ahead of slf4j and logback, both of which still have MDC.
I agree with you that log4j2 is the probably the best solution currently.
-M
On 1/30/2017 5:40 AM, Joern Kottmann wrote:
> In other applications I usually try to add as much as possible context
> information to the MDC, because that can help to find certain problems or
> just understand what was going on.
>
> +1 on using MDC
>
> If we do a v3 release i would remove the old logging APIs if the intention
> is not to use it anymore, users can rather quickly migrate to the new
> logging API of our choice. Also log4j2 is quite nice to use and is probably
> the best solution out there currently.
>
> J�rn
>
> On Sun, Jan 29, 2017 at 4:47 PM, Richard Eckart de Castilho <re...@apache.org>
> wrote:
>
>> On 24.01.2017, at 21:48, Marshall Schor <ms...@schor.com> wrote:
>>> 1) keep the current UIMA logging facade and framework, for backwards
>> compatibility.
>>
>> uimaFIT adds a getLogger() method to its base-classes for reader and
>> engines because
>> getting the logger via the context is just an extra step
>> (getContext().getLogger().error(...) vs
>> getLogger().error(...)).
>>
>> It could be considered adding logging methods directly to the UIMA
>> component base-classes, such
>> that one simply would call "error(...)"? Or introducing a short getter
>> method (log().error(...)))?
>>
>> Cheers,
>>
>> -- Richard
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
In other applications I usually try to add as much as possible context
information to the MDC, because that can help to find certain problems or
just understand what was going on.
+1 on using MDC
If we do a v3 release i would remove the old logging APIs if the intention
is not to use it anymore, users can rather quickly migrate to the new
logging API of our choice. Also log4j2 is quite nice to use and is probably
the best solution out there currently.
Jörn
On Sun, Jan 29, 2017 at 4:47 PM, Richard Eckart de Castilho <re...@apache.org>
wrote:
> On 24.01.2017, at 21:48, Marshall Schor <ms...@schor.com> wrote:
> >
> > 1) keep the current UIMA logging facade and framework, for backwards
> compatibility.
>
> uimaFIT adds a getLogger() method to its base-classes for reader and
> engines because
> getting the logger via the context is just an extra step
> (getContext().getLogger().error(...) vs
> getLogger().error(...)).
>
> It could be considered adding logging methods directly to the UIMA
> component base-classes, such
> that one simply would call "error(...)"? Or introducing a short getter
> method (log().error(...)))?
>
> Cheers,
>
> -- Richard
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 24.01.2017, at 21:48, Marshall Schor <ms...@schor.com> wrote:
>
> 1) keep the current UIMA logging facade and framework, for backwards compatibility.
uimaFIT adds a getLogger() method to its base-classes for reader and engines because
getting the logger via the context is just an extra step (getContext().getLogger().error(...) vs
getLogger().error(...)).
It could be considered adding logging methods directly to the UIMA component base-classes, such
that one simply would call "error(...)"? Or introducing a short getter method (log().error(...)))?
Cheers,
-- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
I felt bad about removing the getSlf4jLogger() form, because there is no
0-argument method for getting a slf4j logger.
So, I'm leaning toward keeping it in...
The advantage is that it's a quicker/shorter way to get the slf4j logger named
for the annotator class implementation name.
The log4j equivalent uses some Oracle internal reflection class to get the
classname of the caller; I think this defaults to a much slower implementation
for non-Oracle JVMs.
-Marshall
On 2/14/2017 4:31 PM, Marshall Schor wrote:
> On 2/14/2017 2:30 PM, Richard Eckart de Castilho wrote:
>>> On 14.02.2017, at 17:26, Marshall Schor <ms...@schor.com> wrote:
>>>
>>> Meanwhile, I renamed the core method to getUimaLogger(), which now is nicely
>>> symmetric with getSlf4jLogger(), so I kind of like it.
>>>
>>> And Joern is suggesting we deprecate the uima loggers in favor of more
>>> conventional ones.
>>> Do you have an opinion on this?
>> Well... I have seen many people not using the UIMA logging framework
>> and instead simply fetching a log4j logger or other logging framework
>> logger and using that.
>>
>> I tend to prefer the UIMA logging framework because that means that
>> UIMA components use the same logging no matter where they are run.
>> It would be annoying if component A would be logging against SLF4J,
>> component B logs against JUL, component C logs against commons-logging,
>> etc.
>>
>> SLF4J is by far the framework with which I have had most problems in the
>> past mainly because many people don't understand that they should not depend
>> on specific backends in their code.
>>
>> Reflecting the name of a particular external (i.e. non-UIMA) logging
>> framework in a UIMA core method leaves me felling a bit uncomfortable.
> The only reason I did this was to permit UIMA itself to start adding MDC/NDC
> context information that loggers could pick up, as well as Markers. The least
> common denominator I found to permit doing that, and not binding a particular
> logging back end was slf4j.
>
>> If we choose to endorse SLF4J, ok - but then I kind of would be with
>> Jrn - people can just obtain the logger themselves. The only benefit
>> I would see is that channeling people through our on logger factory
>> method would provide some control/best practice over the logger
>> naming scheme... but that's typically going by the classname anyway.
> OK.
>> So presently, I would be in favor of dropping "getSlf4jLogger()".
>> I could imagine replicating the SLF4J API in the UIMA logging
>> framework. Not sure about entirely dropping the UIMA logging
>> framework though.
> OK. I think I'll keep the old UIMA framework to reduce the friction of having
> existing pipelines adopt v3, and to allow a longer on - ramp for converting
> (over time, if we desire) UIMA's own use of logging to slf4j + MDC/NDC/Markers.
>
> Thanks for your thoughts! -Marshall
>> Cheers,
>>
>> -- Richard
>>
>>
>>
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
On 2/14/2017 2:30 PM, Richard Eckart de Castilho wrote:
>> On 14.02.2017, at 17:26, Marshall Schor <ms...@schor.com> wrote:
>>
>> Meanwhile, I renamed the core method to getUimaLogger(), which now is nicely
>> symmetric with getSlf4jLogger(), so I kind of like it.
>>
>> And Joern is suggesting we deprecate the uima loggers in favor of more
>> conventional ones.
>> Do you have an opinion on this?
> Well... I have seen many people not using the UIMA logging framework
> and instead simply fetching a log4j logger or other logging framework
> logger and using that.
>
> I tend to prefer the UIMA logging framework because that means that
> UIMA components use the same logging no matter where they are run.
> It would be annoying if component A would be logging against SLF4J,
> component B logs against JUL, component C logs against commons-logging,
> etc.
>
> SLF4J is by far the framework with which I have had most problems in the
> past mainly because many people don't understand that they should not depend
> on specific backends in their code.
>
> Reflecting the name of a particular external (i.e. non-UIMA) logging
> framework in a UIMA core method leaves me felling a bit uncomfortable.
The only reason I did this was to permit UIMA itself to start adding MDC/NDC
context information that loggers could pick up, as well as Markers. The least
common denominator I found to permit doing that, and not binding a particular
logging back end was slf4j.
> If we choose to endorse SLF4J, ok - but then I kind of would be with
> Jrn - people can just obtain the logger themselves. The only benefit
> I would see is that channeling people through our on logger factory
> method would provide some control/best practice over the logger
> naming scheme... but that's typically going by the classname anyway.
OK.
> So presently, I would be in favor of dropping "getSlf4jLogger()".
> I could imagine replicating the SLF4J API in the UIMA logging
> framework. Not sure about entirely dropping the UIMA logging
> framework though.
OK. I think I'll keep the old UIMA framework to reduce the friction of having
existing pipelines adopt v3, and to allow a longer on - ramp for converting
(over time, if we desire) UIMA's own use of logging to slf4j + MDC/NDC/Markers.
Thanks for your thoughts! -Marshall
>
> Cheers,
>
> -- Richard
>
>
>
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
> On 14.02.2017, at 17:26, Marshall Schor <ms...@schor.com> wrote:
>
> Meanwhile, I renamed the core method to getUimaLogger(), which now is nicely
> symmetric with getSlf4jLogger(), so I kind of like it.
>
> And Joern is suggesting we deprecate the uima loggers in favor of more
> conventional ones.
> Do you have an opinion on this?
Well... I have seen many people not using the UIMA logging framework
and instead simply fetching a log4j logger or other logging framework
logger and using that.
I tend to prefer the UIMA logging framework because that means that
UIMA components use the same logging no matter where they are run.
It would be annoying if component A would be logging against SLF4J,
component B logs against JUL, component C logs against commons-logging,
etc.
SLF4J is by far the framework with which I have had most problems in the
past mainly because many people don't understand that they should not depend
on specific backends in their code.
Reflecting the name of a particular external (i.e. non-UIMA) logging
framework in a UIMA core method leaves me felling a bit uncomfortable.
If we choose to endorse SLF4J, ok - but then I kind of would be with
Jörn - people can just obtain the logger themselves. The only benefit
I would see is that channeling people through our on logger factory
method would provide some control/best practice over the logger
naming scheme... but that's typically going by the classname anyway.
So presently, I would be in favor of dropping "getSlf4jLogger()".
I could imagine replicating the SLF4J API in the UIMA logging
framework. Not sure about entirely dropping the UIMA logging
framework though.
Cheers,
-- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
The latest twist:
The uima Logger Interface methods are completely disjoint from the SLF4j Logger
Interface methods.
So, I've added all of the methods from SLF4j Logger to the UIMA logger. These
delegate to the slf4j logger methods.
So I think there's no need anymore for both getUimaLogger() and getSlfjLogger()
methods.
And, if there's no conflict, I'll rename the getUimaLogger() to getLogger() on
the Annotator base impl class.
If you use the -D option to switch to the log4j logger (in V3, this is the
**log4j 2** logger), that logger also implements the slf4j logger's API.
Please report any issues you see with this approach :-)
-Marshall
On 2/14/2017 11:26 AM, Marshall Schor wrote:
> hmmm, this is surprising to me, so I'm wondering if some other configuration of
> things might still show some problems.
>
> Meanwhile, I renamed the core method to getUimaLogger(), which now is nicely
> symmetric with getSlf4jLogger(), so I kind of like it.
>
> And Joern is suggesting we deprecate the uima loggers in favor of more
> conventional ones.
> Do you have an opinion on this?
>
> -Marshall
>
>
> On 2/14/2017 6:10 AM, Richard Eckart de Castilho wrote:
>> On 06.02.2017, at 19:45, Marshall Schor <ms...@schor.com> wrote:
>>> I see the uimaFIT getLogger method is on a class which extends the main UIMA
>>> class which would have getLogger().
>>>
>>> uimaFIT's method would clash, because it returns a different Java type.
>> uimaFIT's ExtendedLogger extends the UIMA Logger.
>>
>> I have tested adding a getLogger() method to AnalysisComponent_ImplBase in UIMA-CORE:
>>
>> protected Logger getLogger()
>> {
>> return getContext().getLogger();
>> }
>>
>> That doesn't seem to clash with the uimaFIT getLogger() declaration:
>>
>> public ExtendedLogger getLogger() {
>> if (logger == null) {
>> logger = new ExtendedLogger(getContext());
>> }
>> return logger;
>> }
>>
>> where ExtendedLogger implements Logger.
>>
>> So I guess we could stay with "getLogger()" instead of "getUimaLogger()".
>>
>> WDYT?
>>
>> Cheers,
>>
>> -- Richard
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
hmmm, this is surprising to me, so I'm wondering if some other configuration of
things might still show some problems.
Meanwhile, I renamed the core method to getUimaLogger(), which now is nicely
symmetric with getSlf4jLogger(), so I kind of like it.
And Joern is suggesting we deprecate the uima loggers in favor of more
conventional ones.
Do you have an opinion on this?
-Marshall
On 2/14/2017 6:10 AM, Richard Eckart de Castilho wrote:
> On 06.02.2017, at 19:45, Marshall Schor <ms...@schor.com> wrote:
>> I see the uimaFIT getLogger method is on a class which extends the main UIMA
>> class which would have getLogger().
>>
>> uimaFIT's method would clash, because it returns a different Java type.
> uimaFIT's ExtendedLogger extends the UIMA Logger.
>
> I have tested adding a getLogger() method to AnalysisComponent_ImplBase in UIMA-CORE:
>
> protected Logger getLogger()
> {
> return getContext().getLogger();
> }
>
> That doesn't seem to clash with the uimaFIT getLogger() declaration:
>
> public ExtendedLogger getLogger() {
> if (logger == null) {
> logger = new ExtendedLogger(getContext());
> }
> return logger;
> }
>
> where ExtendedLogger implements Logger.
>
> So I guess we could stay with "getLogger()" instead of "getUimaLogger()".
>
> WDYT?
>
> Cheers,
>
> -- Richard
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 06.02.2017, at 19:45, Marshall Schor <ms...@schor.com> wrote:
>
> I see the uimaFIT getLogger method is on a class which extends the main UIMA
> class which would have getLogger().
>
> uimaFIT's method would clash, because it returns a different Java type.
uimaFIT's ExtendedLogger extends the UIMA Logger.
I have tested adding a getLogger() method to AnalysisComponent_ImplBase in UIMA-CORE:
protected Logger getLogger()
{
return getContext().getLogger();
}
That doesn't seem to clash with the uimaFIT getLogger() declaration:
public ExtendedLogger getLogger() {
if (logger == null) {
logger = new ExtendedLogger(getContext());
}
return logger;
}
where ExtendedLogger implements Logger.
So I guess we could stay with "getLogger()" instead of "getUimaLogger()".
WDYT?
Cheers,
-- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
oops, hit send too soon.
I see the uimaFIT getLogger method is on a class which extends the main UIMA
class which would have getLogger().
uimaFIT's method would clash, because it returns a different Java type.
I'll pick another name to avoid the clash.
-M
On 2/6/2017 1:29 PM, Marshall Schor wrote:
>
> +1 to not clashing, etc.
>
> I'm not sure they would clash - because the uimaFIT getLogger method is on
>
>
> On 2/3/2017 8:57 AM, Richard Eckart de Castilho wrote:
>> On 02.02.2017, at 17:16, Marshall Schor <ms...@schor.com> wrote:
>>> 3) For Annotators, the base class they extend is augmented with getLogger() and
>>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger with
>>> the name of the Annotator implementation class. getLogger() is just shorthand
>>> for the existing getContext().getLogger() api.
>> It would be nice to make sure that a getLogger() method added to the UIMA core
>> base classes would not clash with the one that the uimaFIT base-classes already
>> provide - or if not, then it means that indeed uimaFIT needs to move to UIMA v3
>> meaning the discussion we had about setting up builds simultaneously against v2
>> and v3 would become obsolete at least for uimaFIT.
>>
>> -- Richard
>
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 02.02.2017, at 17:16, Marshall Schor <ms...@schor.com> wrote:
>
> 3) For Annotators, the base class they extend is augmented with getLogger() and
> getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger with
> the name of the Annotator implementation class. getLogger() is just shorthand
> for the existing getContext().getLogger() api.
It would be nice to make sure that a getLogger() method added to the UIMA core
base classes would not clash with the one that the uimaFIT base-classes already
provide - or if not, then it means that indeed uimaFIT needs to move to UIMA v3
meaning the discussion we had about setting up builds simultaneously against v2
and v3 would become obsolete at least for uimaFIT.
-- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
SLF4j changes the levels:
FINE, FINER, FINEST are gone, "trace" is added.
SEVERE is renamed "error".
CONFIG is gone.
I think CONFIG is best replaced with a "config" marker. This allows config
messages at info / warning / error levels.
Other views?
-Marshall
On 2/2/2017 11:16 AM, Marshall Schor wrote:
> Here's a next iteration of set of ideas for logging support in V3.
>
> 1) Keep the v2 uima logging API - so users can migrate at their own speed (or
> not...)
> - but update the UIMA logger logj4 backend to switch it to log4j-2
>
> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other back-end
> loggers, configurable at deployment time.
>
> - Has MDC and NDC (the stack version of MDC) support
> https://logback.qos.ch/manual/mdc.html
>
> - Has support for efficiency and Java 8 styles (e.g. using "Supplier<String>"
> for messages)
>
> - Has support for Markers
> http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback
>
> 3) For Annotators, the base class they extend is augmented with getLogger() and
> getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger with
> the name of the Annotator implementation class. getLogger() is just shorthand
> for the existing getContext().getLogger() api.
>
> 4) Extend the UIMA logger to externalize the hook to UIMA's resource bundle
> message lookup (which uses the context's ResourceManger's extension class loader
> if defined), so calls using the slf4j apis can use that if desired.
>
> 5) Update the existing documentation on how to configure backends to mention slf4j.
>
> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new to this,
> so please make suggestions for improvement!
>
> a) Add to MDC: the Annotator being run (probably just the class name)
> There are probably other things that should go into the MDC/NDC, but
> I'm not sure what would be useful - suggestions welcome.
>
> b) Use Markers to identify and control logging related to:
>
> - annotator (flow-like tracing?)
>
> - flow_controller
>
> - feature structure (creation, updating) - trace-level
>
> - index (operations like adding to / removing from) -trace-level
>
> - index_copy_on_write - trace-level
>
> - index_auto_rmv_add (when UIMA is automatically removing and adding
> back FSs due to modification of key values) - trace-level
>
> - serdes (serialization / deserialization)
>
> Please consider this a first try; other suggestions welcome :-)
>
> -Marshall
>
>
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
Yeah, I think a is a good default, and in the contexts new users encounter
we just enable some kind of logging (thinking here about debugging AEs in
eclipse with our runner plugin or our getting started tutorials).
Jörn
On Wed, Feb 15, 2017 at 3:37 PM, Marshall Schor <ms...@schor.com> 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 <tw...@gmx.de> 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 <
> >>> rec@apache.org
> >>>
> >>>> wrote:
> >>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
> >>>>
>
>
Re: uima v3 logging - proposal
Posted by Marshall Schor <ms...@schor.com>.
J�rn makes a good point.
There's a general way to pass in parameters to uima pipeline creation, the
"additionalParameters" map. So we could define a new key for this map, which
would set this mode.
Provided that would address the driving use-case for this issue, I'm fine with that.
-Marshall
On 2/17/2017 5:39 AM, Joern Kottmann wrote:
> Setting this global on JVM level might not be nice if you try to run two
> UIMA applications in one process.
> Maybe it might be more reasonable to have a way to pass configuration to a
> UIMA pipeline when it gets created.
>
> J�rn
>
> On Thu, Feb 16, 2017 at 9:47 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> good idea - that provides a way to set things with either -Dxxx or a
>> corresponding API call in Java.
>>
>> Thanks!
>>
>>
>> -Marshall
>>
>>
>> On 2/16/2017 11:57 AM, Richard Eckart de Castilho wrote:
>>> On 16.02.2017, at 14:38, Marshall Schor <ms...@schor.com> wrote:
>>>> A chat with Thilo revealed (regarding setting a flag to suppress
>> annotator
>>>> logging) he doesn't have access to set -D properties for the JVM launch
>> when
>>>> running in his environment (e.g. embedded in some Spark context).
>>>>
>>>> He says an API would work for his use case.
>>>>
>>>> So, instead of the -Duima.suppress_annotator_logging, I propose to add
>> an API
>>>> suppressAnnotatorLogging(boolean) to UIMA in 2 places: one in the
>> UIMAFramework
>>>> and one on the UimaContext. The UIMAFramework one will override if
>> set. The
>>>> context one will affect the annotators running in that context.
>>> What about something like this? That is what I use in DKPro Core JUnit
>> Tests.
>>> // Route logging through log4j
>>> System.setProperty("org.apache.uima.logger.class",
>> "org.apache.uima.util.impl.Log4jLogger_impl");
>>> Cheers,
>>>
>>> -- Richard
>>
Re: uima v3 logging - proposal
Posted by Joern Kottmann <ko...@gmail.com>.
Setting this global on JVM level might not be nice if you try to run two
UIMA applications in one process.
Maybe it might be more reasonable to have a way to pass configuration to a
UIMA pipeline when it gets created.
Jörn
On Thu, Feb 16, 2017 at 9:47 PM, Marshall Schor <ms...@schor.com> wrote:
> good idea - that provides a way to set things with either -Dxxx or a
> corresponding API call in Java.
>
> Thanks!
>
>
> -Marshall
>
>
> On 2/16/2017 11:57 AM, Richard Eckart de Castilho wrote:
> > On 16.02.2017, at 14:38, Marshall Schor <ms...@schor.com> wrote:
> >> A chat with Thilo revealed (regarding setting a flag to suppress
> annotator
> >> logging) he doesn't have access to set -D properties for the JVM launch
> when
> >> running in his environment (e.g. embedded in some Spark context).
> >>
> >> He says an API would work for his use case.
> >>
> >> So, instead of the -Duima.suppress_annotator_logging, I propose to add
> an API
> >> suppressAnnotatorLogging(boolean) to UIMA in 2 places: one in the
> UIMAFramework
> >> and one on the UimaContext. The UIMAFramework one will override if
> set. The
> >> context one will affect the annotators running in that context.
> > What about something like this? That is what I use in DKPro Core JUnit
> Tests.
> >
> > // Route logging through log4j
> > System.setProperty("org.apache.uima.logger.class",
> "org.apache.uima.util.impl.Log4jLogger_impl");
> >
> > Cheers,
> >
> > -- Richard
>
>
Re: uima v3 logging - proposal
Posted by Marshall Schor <ms...@schor.com>.
good idea - that provides a way to set things with either -Dxxx or a
corresponding API call in Java.
Thanks!
-Marshall
On 2/16/2017 11:57 AM, Richard Eckart de Castilho wrote:
> On 16.02.2017, at 14:38, Marshall Schor <ms...@schor.com> wrote:
>> A chat with Thilo revealed (regarding setting a flag to suppress annotator
>> logging) he doesn't have access to set -D properties for the JVM launch when
>> running in his environment (e.g. embedded in some Spark context).
>>
>> He says an API would work for his use case.
>>
>> So, instead of the -Duima.suppress_annotator_logging, I propose to add an API
>> suppressAnnotatorLogging(boolean) to UIMA in 2 places: one in the UIMAFramework
>> and one on the UimaContext. The UIMAFramework one will override if set. The
>> context one will affect the annotators running in that context.
> What about something like this? That is what I use in DKPro Core JUnit Tests.
>
> // Route logging through log4j
> System.setProperty("org.apache.uima.logger.class", "org.apache.uima.util.impl.Log4jLogger_impl");
>
> Cheers,
>
> -- Richard
Re: uima v3 logging - proposal
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 16.02.2017, at 14:38, Marshall Schor <ms...@schor.com> wrote:
>
> A chat with Thilo revealed (regarding setting a flag to suppress annotator
> logging) he doesn't have access to set -D properties for the JVM launch when
> running in his environment (e.g. embedded in some Spark context).
>
> He says an API would work for his use case.
>
> So, instead of the -Duima.suppress_annotator_logging, I propose to add an API
> suppressAnnotatorLogging(boolean) to UIMA in 2 places: one in the UIMAFramework
> and one on the UimaContext. The UIMAFramework one will override if set. The
> context one will affect the annotators running in that context.
What about something like this? That is what I use in DKPro Core JUnit Tests.
// Route logging through log4j
System.setProperty("org.apache.uima.logger.class", "org.apache.uima.util.impl.Log4jLogger_impl");
Cheers,
-- Richard
Re: uima v3 logging - proposal
Posted by Marshall Schor <ms...@schor.com>.
A chat with Thilo revealed (regarding setting a flag to suppress annotator
logging) he doesn't have access to set -D properties for the JVM launch when
running in his environment (e.g. embedded in some Spark context).
He says an API would work for his use case.
So, instead of the -Duima.suppress_annotator_logging, I propose to add an API
suppressAnnotatorLogging(boolean) to UIMA in 2 places: one in the UIMAFramework
and one on the UimaContext. The UIMAFramework one will override if set. The
context one will affect the annotators running in that context.
I've updated the Jira.
-Marshall
On 2/15/2017 5:24 PM, Marshall Schor wrote:
> Please see jira https://issues.apache.org/jira/browse/UIMA-5324 and add your
> comments / corrections / approvals :-)
>
> -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 <tw...@gmx.de> 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 <
>>>>>> rec@apache.org
>>>>>>
>>>>>>> wrote:
>>>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>>>>>
>
Re: uima v3 logging - proposal
Posted by Marshall Schor <ms...@schor.com>.
Please see jira https://issues.apache.org/jira/browse/UIMA-5324 and add your
comments / corrections / approvals :-)
-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 <tw...@gmx.de> 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 <
>>>>> rec@apache.org
>>>>>
>>>>>> wrote:
>>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>>>>
>
Re: uima v3 logging - proposal
Posted by Marshall Schor <ms...@schor.com>.
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 <tw...@gmx.de> 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 <
>>>>> rec@apache.org
>>>>>
>>>>>> wrote:
>>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>>>>
>
Re: uima v3 logging - proposal
Posted by Marshall Schor <ms...@schor.com>.
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 <tw...@gmx.de> 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 <
>>>> rec@apache.org
>>>>
>>>>> wrote:
>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>>>
>
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 15.02.2017, at 16:33, Marshall Schor <ms...@schor.com> wrote:
>
>> 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.).
I think asking people to set the loggers to "OFF" is pretty reasonable.
If people wanted to disable logging entirely, they could install a NOOP logging
facility in UIMA. We could provide such a thing.
I think we're complaining about logging here on a pretty high niveau. What
personally annoys me much more than putting some effort into configuring
and redirecting logging are tools/libraries that actually write to System.out
or System.err. These are the pest and require really annoying drastic measures :/.
Cheers,
-- Richard
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 15.02.2017, at 16:33, Marshall Schor <ms...@schor.com> wrote:
>
>>> 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 embedding context is bound to run on a JRE. So it is a matter of
the embedder to configure the JRE logging facilities to do what he
wants. One option would be to install a JUL-to-SLF4J bridge. Then
the JUL logging would be forwarded to whatever logging backend the
user uses. Unfortunately, AFAIK installing a bridge for JUL requires
actual code to be invoked (dropping in a JAR doesn't seem to suffice).
That is why I personally so far prefer logging against the Apache
Commons Logging API which is easier to redirect.
If we switch entirely to SLF4J for UIMA or even if we just used a
SLF4J implementation as the default backend for the UIMA logging layer,
this problem should be greatly mitigated.
-- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
On 2/15/2017 10:12 AM, Richard Eckart de Castilho wrote:
>> On 15.02.2017, at 15:37, Marshall Schor <ms...@schor.com> 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
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
> On 15.02.2017, at 15:37, Marshall Schor <ms...@schor.com> 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).
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 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).
Cheers,
-- Richard
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
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 <tw...@gmx.de> 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 <
>>> rec@apache.org
>>>
>>>> wrote:
>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>>
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
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 <tw...@gmx.de> 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 <
>> rec@apache.org
>>
>>> wrote:
>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>
>>
>
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
I agree. As a framework it is important to take badly behaved
implementations into account such as our Whitespace AE which prints trace
style messages on INFO log level.
Jörn
On Wed, Feb 15, 2017 at 2:11 PM, Thilo Goetz <tw...@gmx.de> wrote:
>
>
> 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 <
>>>>>> rec@apache.org
>>>>>>
>>>>>>> wrote:
>>>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>>>>>
>>>>>>
>>>
>
Re: uima v3 logging
Posted by Thilo Goetz <tw...@gmx.de>.
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 <rec@apache.org
>>>>>> wrote:
>>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
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
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?
-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 <rec@apache.org
>>>>> wrote:
>>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>>
>
>
Re: uima v3 logging
Posted by Thilo Goetz <tw...@gmx.de>.
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 <rec@apache.org
>>>> wrote:
>>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
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 <rec@apache.org
>>> wrote:
>>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
>
>
Re: uima v3 logging
Posted by Thilo Goetz <tw...@gmx.de>.
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 <rec@apache.org
>> wrote:
>> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
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.
Is that possible with sl4j?
Jörn
On Tue, Feb 14, 2017 at 12:14 PM, Richard Eckart de Castilho <rec@apache.org
> wrote:
> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
On 2/14/2017 6:14 AM, Richard Eckart de Castilho wrote:
> On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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 agree. It's not supposed to have any, but maybe I messed up.
>
> I guess when you talk about "normal binary packaging" you mean the binary release
> package that we do, right?
Yes.
>
> 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).
The Uima Logger is a facade that can be "switched" (just like slf4j - it
predates slf4j) among multiple back ends (3: the built-into-Java logging
framework, the log4j 2 framework, or a simple write to System out (not
documented I think).
For the log4j 2 framework, I had to include a dependency for compiling on the
log4j core. If you don't use the log4j back end, then this code is never
called, and you don't need that jar in the runtime.
The excluding was to have the Bundle build tool (which walks all your classes),
not find these, while doing its work of building the runtime plugin manifest.
The POM has logging dependencies for slf4j (which is a facade, no backend
commitment), and these:
- log4j-api - needed for the bridge code the UIMA logger implements to connect
to this logger if it is specified as the back-end
- log4j-core - needed for the bridge code too
- slf4j-api the new facade
- log4j-slf4j-impl - NOT NEEDED
I can remove this dependency. I'm wondering about including it for convenience
in the binary distribution package, so users, if they use slf4j, will have some
back end available, without extra work.
Opinions?
-Marshall
>
> -- Richard
Re: uima v3 logging
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 06.02.2017, at 21:39, Marshall Schor <ms...@schor.com> 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
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
On 2/12/2017 5:36 AM, Joern Kottmann wrote:
... snip ...
> Lets says we write the annotator name into the mdc. In that case log4j2 can
> use the ThreadContextMapFilter to filter log messages based on properties
> in the mdc.
>
> Have a look here:
> https://logging.apache.org/log4j/2.x/manual/filters.html
>
Good point, I had forgotten this. It looks to be fairly efficient, too.
>
>>> The user will have a hard time making use of that in more serious
>>> applications. It would be awkward to pass the logger reference to other
>>> classes and dependencies might just log directly to our logger backend.
>> I agree. There's a kind of work around for the use case where an Annotator
>> (which would have a named logger) calls other code, perhaps deeply nested,
>> and
>> somewhere deep down, that code wants to log something. If it wants to log
>> using
>> the Uima Logger, it could by using the call
>> UimaContextHolder.getContext().getLogger()
>>
>> SLF4j's way of getting loggers is:
>> Logger.getLogger(String name) or
>> Logger.getLogger(Class clazz)
>>
>> They don't have a 0-argument constructor.
>>
>>
> Maybe I am wrong here but I really don't think it is important that
> annotator name is the same as the logger name, because the annotator name
> should always be in the mdc.
That's true. The purpose of having named loggers is only to divide the 1000's
of logging statements (I'm being very optimistic here :-) ) into sub groups
where you can enable / disable each group separately in the configuration, at
different levels, etc.
Of course, the MDC/NDC setting hasn't yet been implemented - yet - in UIMA.
I'll add a jira for this :-).
The convention (and it's only a convention) is to name the logger to be the same
name as the fully qualified class name where the log statement is.
UIMA was only trying to follow the popular convention of naming loggers in this
manner.
> This should work out of the box until the user starts his own threads
> (because then the mdc will be empty).
Actually, that's also controllable, for log4j, by setting the system property
"isTreadContextMapInheritable" to "true".
https://logging.apache.org/log4j/2.x/manual/thread-context.html - scan down to
near the bottom "Implementation details".
-Marshall
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
On Sun, Feb 12, 2017 at 3:57 AM, Marshall Schor <ms...@schor.com> wrote:
> On 2/11/2017 6:52 PM, Joern Kottmann wrote:
> > Hmm, isn't get getUimaLogger the same as getContext().getLogger() before?
> Yes.
> > In my opinion our goal should be to remove that at some point. UIMA is
> > easier to use for new users when there is not so much confusion with old
> > legacy things around for backward compatibility.
> >
> > For your first point about getLogger(), wouldn't this be solved by the
> MDC?
> > The annotator name is always present in the context.
> I think there are two ways the annotator name is used in logging. One is
> to
> provide information (this is what the MDC does, I believe), and the other
> is to
> provide filtering - in that each "named" logger can have a
> configured-at-deploy-time-level-spec. I don't think there is a simple
> direct
> way to say I want to run a particular annotator at "trace" level, for
> example,
> without that annotator name being the name of a logger that you get with
> getUimaLogger().
>
> But, maybe I don't fully understand this - logging details are fairly new
> to me...
>
> If this is true, then you still need to have named loggers in order to
> filter.
>
Lets says we write the annotator name into the mdc. In that case log4j2 can
use the ThreadContextMapFilter to filter log messages based on properties
in the mdc.
Have a look here:
https://logging.apache.org/log4j/2.x/manual/filters.html
> >
> > The user will have a hard time making use of that in more serious
> > applications. It would be awkward to pass the logger reference to other
> > classes and dependencies might just log directly to our logger backend.
> I agree. There's a kind of work around for the use case where an Annotator
> (which would have a named logger) calls other code, perhaps deeply nested,
> and
> somewhere deep down, that code wants to log something. If it wants to log
> using
> the Uima Logger, it could by using the call
> UimaContextHolder.getContext().getLogger()
>
> SLF4j's way of getting loggers is:
> Logger.getLogger(String name) or
> Logger.getLogger(Class clazz)
>
> They don't have a 0-argument constructor.
>
>
Maybe I am wrong here but I really don't think it is important that
annotator name is the same as the logger name, because the annotator name
should always be in the mdc.
This should work out of the box until the user starts his own threads
(because then the mdc will be empty).
Jörn
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
On 2/11/2017 6:52 PM, Joern Kottmann wrote:
> Hmm, isn't get getUimaLogger the same as getContext().getLogger() before?
Yes.
> In my opinion our goal should be to remove that at some point. UIMA is
> easier to use for new users when there is not so much confusion with old
> legacy things around for backward compatibility.
>
> For your first point about getLogger(), wouldn't this be solved by the MDC?
> The annotator name is always present in the context.
I think there are two ways the annotator name is used in logging. One is to
provide information (this is what the MDC does, I believe), and the other is to
provide filtering - in that each "named" logger can have a
configured-at-deploy-time-level-spec. I don't think there is a simple direct
way to say I want to run a particular annotator at "trace" level, for example,
without that annotator name being the name of a logger that you get with
getUimaLogger().
But, maybe I don't fully understand this - logging details are fairly new to me...
If this is true, then you still need to have named loggers in order to filter.
>
> The user will have a hard time making use of that in more serious
> applications. It would be awkward to pass the logger reference to other
> classes and dependencies might just log directly to our logger backend.
I agree. There's a kind of work around for the use case where an Annotator
(which would have a named logger) calls other code, perhaps deeply nested, and
somewhere deep down, that code wants to log something. If it wants to log using
the Uima Logger, it could by using the call
UimaContextHolder.getContext().getLogger()
SLF4j's way of getting loggers is:
Logger.getLogger(String name) or
Logger.getLogger(Class clazz)
They don't have a 0-argument constructor.
-Marshall
>
> J�rn
>
> On Fri, Feb 10, 2017 at 4:58 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> Here are differences between getLogger() (now renamed gateUimaLogger()) and
>> LogManager.getLogger() or variants.
>>
>> 1) Every logger is "named". The no argument version of getLogger()
>> normally
>> defaults this name to the caller's fully qualified class name.
>> For UIMA loggers, this is somewhat different. It is set to be the
>> Annotator's
>> class name (normally the same thing), but this would be different if the
>> logger
>> is requested from some sub class.
>>
>> 2) The UIMA logger is hooked up to internationalization Resource Bundles,
>> via
>> the UIMA classpath/datapath mechanism. This hook requires access to the
>> UIMA
>> Context to do the resource bundle lookups.
>>
>> If you're not using any of those features, then you can do as you suggest,
>> of
>> course.
>>
>> -Marshall
>>
>>
>>
>> On 2/10/2017 5:46 AM, Joern Kottmann wrote:
>>> I had just read through this quickly. And the one thing that stands out
>>> here for me is the fact,
>>> that you discuss to add some sort of a getLogger method which can be used
>>> by Annotators.
>>>
>>> Why would you do that?
>>>
>>> If I want to get a logger - and we using log4j2 to in the backend i can
>>> just write LogManager.getLogger()
>>> and I have a logger which will log my messages with MDC (because UIMA
>> will
>>> take care of that for me).
>>>
>>> If I have to use some other logger (e.g. forced down on me by
>> dependencies)
>>> I have to deal myself with forwarding that to log4j2,
>>> depending on what is used it might be a matter of the right dependencies
>>> (thinking about slf4j here) or some custom code.
>>>
>>> The existing getLogger method should definitely be deprecated and removed
>>> with some later 3.x release.
>>>
>>> J�rn
>>>
>>>
>>> On Mon, Feb 6, 2017 at 9:39 PM, Marshall Schor <ms...@schor.com> 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.
>>>> -Marshall
>>>>
>>>> On 2/6/2017 3:29 PM, Marshall Schor wrote:
>>>>> I'm trying to think through how to get slf4j to work "nicely" with
>>>> eclipse plugins.
>>>>> Using slf4j, you are supposed to get the benefit of deferring till
>>>> "deploy"
>>>>> time, what back end, and what logging configuration is in use. We
>> need a
>>>>> solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
>>>>>
>>>>> For non-OSGi, we have dependencies on slf4j-api; the maven dependencies
>>>> are for
>>>>> slf4j-api + some back end.
>>>>> (Slight twist: for the logback backend, it also provides the slf4j-api
>>>>> implementation, so to use that, you have to "exclude" the slf4j-api JAR
>>>> if it
>>>>> was included).
>>>>>
>>>>> For OSGi, we either need to have a OSGi style dependency, or package
>> the
>>>> runtime
>>>>> with the plugin. Doing this latter breaks the advantage of being able
>>>> to defer
>>>>> until "deploy" time the particular logging back end.
>>>>>
>>>>> To do the dependency as an OSGi thing, we could (as a default) use the
>>>>> dependency on m2e-slf4j-logback plugin; this comes with m2e as an
>>>> "optional"
>>>>> plugin. Embedders who wanted alternatives could instead install other
>>>>> components. See this for background:
>>>>> http://stackoverflow.com/questions/17352485/error-m2e-
>> install-in-eclipse
>>>>> * for each plugin which might want to depend on slf4j APIs (includes
>>>> "runtime",
>>>>> maybe others)
>>>>>
>>>>> ** add OSGi dependency on the m2e - slf4j over logback logging (This
>> is
>>>>> installed optionally when you install the m2e support)
>>>>>
>>>>> For non OSGi build/test, some slf4j impl + backend is needed. I'm
>>>> thinking of
>>>>> also using the logback implementation which has both.
>>>>>
>>>>> For binary packaging: we need to ship something so this works "out of
>>>> the box"
>>>>> but can be substituted. Again, I'm thinking of using logback
>>>> implementation combo.
>>>>> I'd welcome other informed views, as this is a somewhat new area for me
>>>> to think
>>>>> about.
>>>>>
>>>>> -Marshall
>>>>>
>>>>> On 2/2/2017 11:16 AM, Marshall Schor wrote:
>>>>>> Here's a next iteration of set of ideas for logging support in V3.
>>>>>>
>>>>>> 1) Keep the v2 uima logging API - so users can migrate at their own
>>>> speed (or
>>>>>> not...)
>>>>>> - but update the UIMA logger logj4 backend to switch it to log4j-2
>>>>>>
>>>>>> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other
>>>> back-end
>>>>>> loggers, configurable at deployment time.
>>>>>>
>>>>>> - Has MDC and NDC (the stack version of MDC) support
>>>>>> https://logback.qos.ch/manual/mdc.html
>>>>>>
>>>>>> - Has support for efficiency and Java 8 styles (e.g. using
>>>> "Supplier<String>"
>>>>>> for messages)
>>>>>>
>>>>>> - Has support for Markers
>>>>>> http://stackoverflow.com/questions/4165558/best-
>>>> practices-for-using-markers-in-slf4j-logback
>>>>>> 3) For Annotators, the base class they extend is augmented with
>>>> getLogger() and
>>>>>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j
>>>> logger with
>>>>>> the name of the Annotator implementation class. getLogger() is just
>>>> shorthand
>>>>>> for the existing getContext().getLogger() api.
>>>>>>
>>>>>> 4) Extend the UIMA logger to externalize the hook to UIMA's resource
>>>> bundle
>>>>>> message lookup (which uses the context's ResourceManger's extension
>>>> class loader
>>>>>> if defined), so calls using the slf4j apis can use that if desired.
>>>>>>
>>>>>> 5) Update the existing documentation on how to configure backends to
>>>> mention slf4j.
>>>>>> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new
>>>> to this,
>>>>>> so please make suggestions for improvement!
>>>>>>
>>>>>> a) Add to MDC: the Annotator being run (probably just the class
>> name)
>>>>>> There are probably other things that should go into the MDC/NDC,
>>>> but
>>>>>> I'm not sure what would be useful - suggestions welcome.
>>>>>>
>>>>>> b) Use Markers to identify and control logging related to:
>>>>>>
>>>>>> - annotator (flow-like tracing?)
>>>>>>
>>>>>> - flow_controller
>>>>>>
>>>>>> - feature structure (creation, updating) - trace-level
>>>>>>
>>>>>> - index (operations like adding to / removing from)
>>>> -trace-level
>>>>>> - index_copy_on_write - trace-level
>>>>>>
>>>>>> - index_auto_rmv_add (when UIMA is automatically removing and
>>>> adding
>>>>>> back FSs due to modification of key values) - trace-level
>>>>>>
>>>>>> - serdes (serialization / deserialization)
>>>>>>
>>>>>> Please consider this a first try; other suggestions welcome :-)
>>>>>>
>>>>>> -Marshall
>>>>>>
>>>>>>
>>
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
Hmm, isn't get getUimaLogger the same as getContext().getLogger() before?
In my opinion our goal should be to remove that at some point. UIMA is
easier to use for new users when there is not so much confusion with old
legacy things around for backward compatibility.
For your first point about getLogger(), wouldn't this be solved by the MDC?
The annotator name is always present in the context.
The user will have a hard time making use of that in more serious
applications. It would be awkward to pass the logger reference to other
classes and dependencies might just log directly to our logger backend.
Jörn
On Fri, Feb 10, 2017 at 4:58 PM, Marshall Schor <ms...@schor.com> wrote:
> Here are differences between getLogger() (now renamed gateUimaLogger()) and
> LogManager.getLogger() or variants.
>
> 1) Every logger is "named". The no argument version of getLogger()
> normally
> defaults this name to the caller's fully qualified class name.
> For UIMA loggers, this is somewhat different. It is set to be the
> Annotator's
> class name (normally the same thing), but this would be different if the
> logger
> is requested from some sub class.
>
> 2) The UIMA logger is hooked up to internationalization Resource Bundles,
> via
> the UIMA classpath/datapath mechanism. This hook requires access to the
> UIMA
> Context to do the resource bundle lookups.
>
> If you're not using any of those features, then you can do as you suggest,
> of
> course.
>
> -Marshall
>
>
>
> On 2/10/2017 5:46 AM, Joern Kottmann wrote:
> > I had just read through this quickly. And the one thing that stands out
> > here for me is the fact,
> > that you discuss to add some sort of a getLogger method which can be used
> > by Annotators.
> >
> > Why would you do that?
> >
> > If I want to get a logger - and we using log4j2 to in the backend i can
> > just write LogManager.getLogger()
> > and I have a logger which will log my messages with MDC (because UIMA
> will
> > take care of that for me).
> >
> > If I have to use some other logger (e.g. forced down on me by
> dependencies)
> > I have to deal myself with forwarding that to log4j2,
> > depending on what is used it might be a matter of the right dependencies
> > (thinking about slf4j here) or some custom code.
> >
> > The existing getLogger method should definitely be deprecated and removed
> > with some later 3.x release.
> >
> > Jörn
> >
> >
> > On Mon, Feb 6, 2017 at 9:39 PM, Marshall Schor <ms...@schor.com> 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.
> >> -Marshall
> >>
> >> On 2/6/2017 3:29 PM, Marshall Schor wrote:
> >>> I'm trying to think through how to get slf4j to work "nicely" with
> >> eclipse plugins.
> >>> Using slf4j, you are supposed to get the benefit of deferring till
> >> "deploy"
> >>> time, what back end, and what logging configuration is in use. We
> need a
> >>> solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
> >>>
> >>> For non-OSGi, we have dependencies on slf4j-api; the maven dependencies
> >> are for
> >>> slf4j-api + some back end.
> >>> (Slight twist: for the logback backend, it also provides the slf4j-api
> >>> implementation, so to use that, you have to "exclude" the slf4j-api JAR
> >> if it
> >>> was included).
> >>>
> >>> For OSGi, we either need to have a OSGi style dependency, or package
> the
> >> runtime
> >>> with the plugin. Doing this latter breaks the advantage of being able
> >> to defer
> >>> until "deploy" time the particular logging back end.
> >>>
> >>> To do the dependency as an OSGi thing, we could (as a default) use the
> >>> dependency on m2e-slf4j-logback plugin; this comes with m2e as an
> >> "optional"
> >>> plugin. Embedders who wanted alternatives could instead install other
> >>> components. See this for background:
> >>> http://stackoverflow.com/questions/17352485/error-m2e-
> install-in-eclipse
> >>>
> >>> * for each plugin which might want to depend on slf4j APIs (includes
> >> "runtime",
> >>> maybe others)
> >>>
> >>> ** add OSGi dependency on the m2e - slf4j over logback logging (This
> is
> >>> installed optionally when you install the m2e support)
> >>>
> >>> For non OSGi build/test, some slf4j impl + backend is needed. I'm
> >> thinking of
> >>> also using the logback implementation which has both.
> >>>
> >>> For binary packaging: we need to ship something so this works "out of
> >> the box"
> >>> but can be substituted. Again, I'm thinking of using logback
> >> implementation combo.
> >>> I'd welcome other informed views, as this is a somewhat new area for me
> >> to think
> >>> about.
> >>>
> >>> -Marshall
> >>>
> >>> On 2/2/2017 11:16 AM, Marshall Schor wrote:
> >>>> Here's a next iteration of set of ideas for logging support in V3.
> >>>>
> >>>> 1) Keep the v2 uima logging API - so users can migrate at their own
> >> speed (or
> >>>> not...)
> >>>> - but update the UIMA logger logj4 backend to switch it to log4j-2
> >>>>
> >>>> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other
> >> back-end
> >>>> loggers, configurable at deployment time.
> >>>>
> >>>> - Has MDC and NDC (the stack version of MDC) support
> >>>> https://logback.qos.ch/manual/mdc.html
> >>>>
> >>>> - Has support for efficiency and Java 8 styles (e.g. using
> >> "Supplier<String>"
> >>>> for messages)
> >>>>
> >>>> - Has support for Markers
> >>>> http://stackoverflow.com/questions/4165558/best-
> >> practices-for-using-markers-in-slf4j-logback
> >>>> 3) For Annotators, the base class they extend is augmented with
> >> getLogger() and
> >>>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j
> >> logger with
> >>>> the name of the Annotator implementation class. getLogger() is just
> >> shorthand
> >>>> for the existing getContext().getLogger() api.
> >>>>
> >>>> 4) Extend the UIMA logger to externalize the hook to UIMA's resource
> >> bundle
> >>>> message lookup (which uses the context's ResourceManger's extension
> >> class loader
> >>>> if defined), so calls using the slf4j apis can use that if desired.
> >>>>
> >>>> 5) Update the existing documentation on how to configure backends to
> >> mention slf4j.
> >>>> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new
> >> to this,
> >>>> so please make suggestions for improvement!
> >>>>
> >>>> a) Add to MDC: the Annotator being run (probably just the class
> name)
> >>>> There are probably other things that should go into the MDC/NDC,
> >> but
> >>>> I'm not sure what would be useful - suggestions welcome.
> >>>>
> >>>> b) Use Markers to identify and control logging related to:
> >>>>
> >>>> - annotator (flow-like tracing?)
> >>>>
> >>>> - flow_controller
> >>>>
> >>>> - feature structure (creation, updating) - trace-level
> >>>>
> >>>> - index (operations like adding to / removing from)
> >> -trace-level
> >>>> - index_copy_on_write - trace-level
> >>>>
> >>>> - index_auto_rmv_add (when UIMA is automatically removing and
> >> adding
> >>>> back FSs due to modification of key values) - trace-level
> >>>>
> >>>> - serdes (serialization / deserialization)
> >>>>
> >>>> Please consider this a first try; other suggestions welcome :-)
> >>>>
> >>>> -Marshall
> >>>>
> >>>>
> >>
>
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
Here are differences between getLogger() (now renamed gateUimaLogger()) and
LogManager.getLogger() or variants.
1) Every logger is "named". The no argument version of getLogger() normally
defaults this name to the caller's fully qualified class name.
For UIMA loggers, this is somewhat different. It is set to be the Annotator's
class name (normally the same thing), but this would be different if the logger
is requested from some sub class.
2) The UIMA logger is hooked up to internationalization Resource Bundles, via
the UIMA classpath/datapath mechanism. This hook requires access to the UIMA
Context to do the resource bundle lookups.
If you're not using any of those features, then you can do as you suggest, of
course.
-Marshall
On 2/10/2017 5:46 AM, Joern Kottmann wrote:
> I had just read through this quickly. And the one thing that stands out
> here for me is the fact,
> that you discuss to add some sort of a getLogger method which can be used
> by Annotators.
>
> Why would you do that?
>
> If I want to get a logger - and we using log4j2 to in the backend i can
> just write LogManager.getLogger()
> and I have a logger which will log my messages with MDC (because UIMA will
> take care of that for me).
>
> If I have to use some other logger (e.g. forced down on me by dependencies)
> I have to deal myself with forwarding that to log4j2,
> depending on what is used it might be a matter of the right dependencies
> (thinking about slf4j here) or some custom code.
>
> The existing getLogger method should definitely be deprecated and removed
> with some later 3.x release.
>
> J�rn
>
>
> On Mon, Feb 6, 2017 at 9:39 PM, Marshall Schor <ms...@schor.com> 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.
>> -Marshall
>>
>> On 2/6/2017 3:29 PM, Marshall Schor wrote:
>>> I'm trying to think through how to get slf4j to work "nicely" with
>> eclipse plugins.
>>> Using slf4j, you are supposed to get the benefit of deferring till
>> "deploy"
>>> time, what back end, and what logging configuration is in use. We need a
>>> solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
>>>
>>> For non-OSGi, we have dependencies on slf4j-api; the maven dependencies
>> are for
>>> slf4j-api + some back end.
>>> (Slight twist: for the logback backend, it also provides the slf4j-api
>>> implementation, so to use that, you have to "exclude" the slf4j-api JAR
>> if it
>>> was included).
>>>
>>> For OSGi, we either need to have a OSGi style dependency, or package the
>> runtime
>>> with the plugin. Doing this latter breaks the advantage of being able
>> to defer
>>> until "deploy" time the particular logging back end.
>>>
>>> To do the dependency as an OSGi thing, we could (as a default) use the
>>> dependency on m2e-slf4j-logback plugin; this comes with m2e as an
>> "optional"
>>> plugin. Embedders who wanted alternatives could instead install other
>>> components. See this for background:
>>> http://stackoverflow.com/questions/17352485/error-m2e-install-in-eclipse
>>>
>>> * for each plugin which might want to depend on slf4j APIs (includes
>> "runtime",
>>> maybe others)
>>>
>>> ** add OSGi dependency on the m2e - slf4j over logback logging (This is
>>> installed optionally when you install the m2e support)
>>>
>>> For non OSGi build/test, some slf4j impl + backend is needed. I'm
>> thinking of
>>> also using the logback implementation which has both.
>>>
>>> For binary packaging: we need to ship something so this works "out of
>> the box"
>>> but can be substituted. Again, I'm thinking of using logback
>> implementation combo.
>>> I'd welcome other informed views, as this is a somewhat new area for me
>> to think
>>> about.
>>>
>>> -Marshall
>>>
>>> On 2/2/2017 11:16 AM, Marshall Schor wrote:
>>>> Here's a next iteration of set of ideas for logging support in V3.
>>>>
>>>> 1) Keep the v2 uima logging API - so users can migrate at their own
>> speed (or
>>>> not...)
>>>> - but update the UIMA logger logj4 backend to switch it to log4j-2
>>>>
>>>> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other
>> back-end
>>>> loggers, configurable at deployment time.
>>>>
>>>> - Has MDC and NDC (the stack version of MDC) support
>>>> https://logback.qos.ch/manual/mdc.html
>>>>
>>>> - Has support for efficiency and Java 8 styles (e.g. using
>> "Supplier<String>"
>>>> for messages)
>>>>
>>>> - Has support for Markers
>>>> http://stackoverflow.com/questions/4165558/best-
>> practices-for-using-markers-in-slf4j-logback
>>>> 3) For Annotators, the base class they extend is augmented with
>> getLogger() and
>>>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j
>> logger with
>>>> the name of the Annotator implementation class. getLogger() is just
>> shorthand
>>>> for the existing getContext().getLogger() api.
>>>>
>>>> 4) Extend the UIMA logger to externalize the hook to UIMA's resource
>> bundle
>>>> message lookup (which uses the context's ResourceManger's extension
>> class loader
>>>> if defined), so calls using the slf4j apis can use that if desired.
>>>>
>>>> 5) Update the existing documentation on how to configure backends to
>> mention slf4j.
>>>> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new
>> to this,
>>>> so please make suggestions for improvement!
>>>>
>>>> a) Add to MDC: the Annotator being run (probably just the class name)
>>>> There are probably other things that should go into the MDC/NDC,
>> but
>>>> I'm not sure what would be useful - suggestions welcome.
>>>>
>>>> b) Use Markers to identify and control logging related to:
>>>>
>>>> - annotator (flow-like tracing?)
>>>>
>>>> - flow_controller
>>>>
>>>> - feature structure (creation, updating) - trace-level
>>>>
>>>> - index (operations like adding to / removing from)
>> -trace-level
>>>> - index_copy_on_write - trace-level
>>>>
>>>> - index_auto_rmv_add (when UIMA is automatically removing and
>> adding
>>>> back FSs due to modification of key values) - trace-level
>>>>
>>>> - serdes (serialization / deserialization)
>>>>
>>>> Please consider this a first try; other suggestions welcome :-)
>>>>
>>>> -Marshall
>>>>
>>>>
>>
Re: uima v3 logging
Posted by Joern Kottmann <ko...@gmail.com>.
I had just read through this quickly. And the one thing that stands out
here for me is the fact,
that you discuss to add some sort of a getLogger method which can be used
by Annotators.
Why would you do that?
If I want to get a logger - and we using log4j2 to in the backend i can
just write LogManager.getLogger()
and I have a logger which will log my messages with MDC (because UIMA will
take care of that for me).
If I have to use some other logger (e.g. forced down on me by dependencies)
I have to deal myself with forwarding that to log4j2,
depending on what is used it might be a matter of the right dependencies
(thinking about slf4j here) or some custom code.
The existing getLogger method should definitely be deprecated and removed
with some later 3.x release.
Jörn
On Mon, Feb 6, 2017 at 9:39 PM, Marshall Schor <ms...@schor.com> 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.
> -Marshall
>
> On 2/6/2017 3:29 PM, Marshall Schor wrote:
> > I'm trying to think through how to get slf4j to work "nicely" with
> eclipse plugins.
> >
> > Using slf4j, you are supposed to get the benefit of deferring till
> "deploy"
> > time, what back end, and what logging configuration is in use. We need a
> > solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
> >
> > For non-OSGi, we have dependencies on slf4j-api; the maven dependencies
> are for
> > slf4j-api + some back end.
> > (Slight twist: for the logback backend, it also provides the slf4j-api
> > implementation, so to use that, you have to "exclude" the slf4j-api JAR
> if it
> > was included).
> >
> > For OSGi, we either need to have a OSGi style dependency, or package the
> runtime
> > with the plugin. Doing this latter breaks the advantage of being able
> to defer
> > until "deploy" time the particular logging back end.
> >
> > To do the dependency as an OSGi thing, we could (as a default) use the
> > dependency on m2e-slf4j-logback plugin; this comes with m2e as an
> "optional"
> > plugin. Embedders who wanted alternatives could instead install other
> > components. See this for background:
> > http://stackoverflow.com/questions/17352485/error-m2e-install-in-eclipse
> >
> > * for each plugin which might want to depend on slf4j APIs (includes
> "runtime",
> > maybe others)
> >
> > ** add OSGi dependency on the m2e - slf4j over logback logging (This is
> > installed optionally when you install the m2e support)
> >
> > For non OSGi build/test, some slf4j impl + backend is needed. I'm
> thinking of
> > also using the logback implementation which has both.
> >
> > For binary packaging: we need to ship something so this works "out of
> the box"
> > but can be substituted. Again, I'm thinking of using logback
> implementation combo.
> >
> > I'd welcome other informed views, as this is a somewhat new area for me
> to think
> > about.
> >
> > -Marshall
> >
> > On 2/2/2017 11:16 AM, Marshall Schor wrote:
> >> Here's a next iteration of set of ideas for logging support in V3.
> >>
> >> 1) Keep the v2 uima logging API - so users can migrate at their own
> speed (or
> >> not...)
> >> - but update the UIMA logger logj4 backend to switch it to log4j-2
> >>
> >> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other
> back-end
> >> loggers, configurable at deployment time.
> >>
> >> - Has MDC and NDC (the stack version of MDC) support
> >> https://logback.qos.ch/manual/mdc.html
> >>
> >> - Has support for efficiency and Java 8 styles (e.g. using
> "Supplier<String>"
> >> for messages)
> >>
> >> - Has support for Markers
> >> http://stackoverflow.com/questions/4165558/best-
> practices-for-using-markers-in-slf4j-logback
> >>
> >> 3) For Annotators, the base class they extend is augmented with
> getLogger() and
> >> getSlf4jLogger(); these return either the UIMA logger or an SLF4j
> logger with
> >> the name of the Annotator implementation class. getLogger() is just
> shorthand
> >> for the existing getContext().getLogger() api.
> >>
> >> 4) Extend the UIMA logger to externalize the hook to UIMA's resource
> bundle
> >> message lookup (which uses the context's ResourceManger's extension
> class loader
> >> if defined), so calls using the slf4j apis can use that if desired.
> >>
> >> 5) Update the existing documentation on how to configure backends to
> mention slf4j.
> >>
> >> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new
> to this,
> >> so please make suggestions for improvement!
> >>
> >> a) Add to MDC: the Annotator being run (probably just the class name)
> >> There are probably other things that should go into the MDC/NDC,
> but
> >> I'm not sure what would be useful - suggestions welcome.
> >>
> >> b) Use Markers to identify and control logging related to:
> >>
> >> - annotator (flow-like tracing?)
> >>
> >> - flow_controller
> >>
> >> - feature structure (creation, updating) - trace-level
> >>
> >> - index (operations like adding to / removing from)
> -trace-level
> >>
> >> - index_copy_on_write - trace-level
> >>
> >> - index_auto_rmv_add (when UIMA is automatically removing and
> adding
> >> back FSs due to modification of key values) - trace-level
> >>
> >> - serdes (serialization / deserialization)
> >>
> >> Please consider this a first try; other suggestions welcome :-)
> >>
> >> -Marshall
> >>
> >>
> >
>
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
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.
-Marshall
On 2/6/2017 3:29 PM, Marshall Schor wrote:
> I'm trying to think through how to get slf4j to work "nicely" with eclipse plugins.
>
> Using slf4j, you are supposed to get the benefit of deferring till "deploy"
> time, what back end, and what logging configuration is in use. We need a
> solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
>
> For non-OSGi, we have dependencies on slf4j-api; the maven dependencies are for
> slf4j-api + some back end.
> (Slight twist: for the logback backend, it also provides the slf4j-api
> implementation, so to use that, you have to "exclude" the slf4j-api JAR if it
> was included).
>
> For OSGi, we either need to have a OSGi style dependency, or package the runtime
> with the plugin. Doing this latter breaks the advantage of being able to defer
> until "deploy" time the particular logging back end.
>
> To do the dependency as an OSGi thing, we could (as a default) use the
> dependency on m2e-slf4j-logback plugin; this comes with m2e as an "optional"
> plugin. Embedders who wanted alternatives could instead install other
> components. See this for background:
> http://stackoverflow.com/questions/17352485/error-m2e-install-in-eclipse
>
> * for each plugin which might want to depend on slf4j APIs (includes "runtime",
> maybe others)
>
> ** add OSGi dependency on the m2e - slf4j over logback logging (This is
> installed optionally when you install the m2e support)
>
> For non OSGi build/test, some slf4j impl + backend is needed. I'm thinking of
> also using the logback implementation which has both.
>
> For binary packaging: we need to ship something so this works "out of the box"
> but can be substituted. Again, I'm thinking of using logback implementation combo.
>
> I'd welcome other informed views, as this is a somewhat new area for me to think
> about.
>
> -Marshall
>
> On 2/2/2017 11:16 AM, Marshall Schor wrote:
>> Here's a next iteration of set of ideas for logging support in V3.
>>
>> 1) Keep the v2 uima logging API - so users can migrate at their own speed (or
>> not...)
>> - but update the UIMA logger logj4 backend to switch it to log4j-2
>>
>> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other back-end
>> loggers, configurable at deployment time.
>>
>> - Has MDC and NDC (the stack version of MDC) support
>> https://logback.qos.ch/manual/mdc.html
>>
>> - Has support for efficiency and Java 8 styles (e.g. using "Supplier<String>"
>> for messages)
>>
>> - Has support for Markers
>> http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback
>>
>> 3) For Annotators, the base class they extend is augmented with getLogger() and
>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger with
>> the name of the Annotator implementation class. getLogger() is just shorthand
>> for the existing getContext().getLogger() api.
>>
>> 4) Extend the UIMA logger to externalize the hook to UIMA's resource bundle
>> message lookup (which uses the context's ResourceManger's extension class loader
>> if defined), so calls using the slf4j apis can use that if desired.
>>
>> 5) Update the existing documentation on how to configure backends to mention slf4j.
>>
>> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new to this,
>> so please make suggestions for improvement!
>>
>> a) Add to MDC: the Annotator being run (probably just the class name)
>> There are probably other things that should go into the MDC/NDC, but
>> I'm not sure what would be useful - suggestions welcome.
>>
>> b) Use Markers to identify and control logging related to:
>>
>> - annotator (flow-like tracing?)
>>
>> - flow_controller
>>
>> - feature structure (creation, updating) - trace-level
>>
>> - index (operations like adding to / removing from) -trace-level
>>
>> - index_copy_on_write - trace-level
>>
>> - index_auto_rmv_add (when UIMA is automatically removing and adding
>> back FSs due to modification of key values) - trace-level
>>
>> - serdes (serialization / deserialization)
>>
>> Please consider this a first try; other suggestions welcome :-)
>>
>> -Marshall
>>
>>
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
I'm trying to think through how to get slf4j to work "nicely" with eclipse plugins.
Using slf4j, you are supposed to get the benefit of deferring till "deploy"
time, what back end, and what logging configuration is in use. We need a
solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
For non-OSGi, we have dependencies on slf4j-api; the maven dependencies are for
slf4j-api + some back end.
(Slight twist: for the logback backend, it also provides the slf4j-api
implementation, so to use that, you have to "exclude" the slf4j-api JAR if it
was included).
For OSGi, we either need to have a OSGi style dependency, or package the runtime
with the plugin. Doing this latter breaks the advantage of being able to defer
until "deploy" time the particular logging back end.
To do the dependency as an OSGi thing, we could (as a default) use the
dependency on m2e-slf4j-logback plugin; this comes with m2e as an "optional"
plugin. Embedders who wanted alternatives could instead install other
components. See this for background:
http://stackoverflow.com/questions/17352485/error-m2e-install-in-eclipse
* for each plugin which might want to depend on slf4j APIs (includes "runtime",
maybe others)
** add OSGi dependency on the m2e - slf4j over logback logging (This is
installed optionally when you install the m2e support)
For non OSGi build/test, some slf4j impl + backend is needed. I'm thinking of
also using the logback implementation which has both.
For binary packaging: we need to ship something so this works "out of the box"
but can be substituted. Again, I'm thinking of using logback implementation combo.
I'd welcome other informed views, as this is a somewhat new area for me to think
about.
-Marshall
On 2/2/2017 11:16 AM, Marshall Schor wrote:
> Here's a next iteration of set of ideas for logging support in V3.
>
> 1) Keep the v2 uima logging API - so users can migrate at their own speed (or
> not...)
> - but update the UIMA logger logj4 backend to switch it to log4j-2
>
> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other back-end
> loggers, configurable at deployment time.
>
> - Has MDC and NDC (the stack version of MDC) support
> https://logback.qos.ch/manual/mdc.html
>
> - Has support for efficiency and Java 8 styles (e.g. using "Supplier<String>"
> for messages)
>
> - Has support for Markers
> http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback
>
> 3) For Annotators, the base class they extend is augmented with getLogger() and
> getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger with
> the name of the Annotator implementation class. getLogger() is just shorthand
> for the existing getContext().getLogger() api.
>
> 4) Extend the UIMA logger to externalize the hook to UIMA's resource bundle
> message lookup (which uses the context's ResourceManger's extension class loader
> if defined), so calls using the slf4j apis can use that if desired.
>
> 5) Update the existing documentation on how to configure backends to mention slf4j.
>
> 6) A plan to make use of the the slf4j logging in core UIMA. I'm new to this,
> so please make suggestions for improvement!
>
> a) Add to MDC: the Annotator being run (probably just the class name)
> There are probably other things that should go into the MDC/NDC, but
> I'm not sure what would be useful - suggestions welcome.
>
> b) Use Markers to identify and control logging related to:
>
> - annotator (flow-like tracing?)
>
> - flow_controller
>
> - feature structure (creation, updating) - trace-level
>
> - index (operations like adding to / removing from) -trace-level
>
> - index_copy_on_write - trace-level
>
> - index_auto_rmv_add (when UIMA is automatically removing and adding
> back FSs due to modification of key values) - trace-level
>
> - serdes (serialization / deserialization)
>
> Please consider this a first try; other suggestions welcome :-)
>
> -Marshall
>
>
Re: uima v3 logging
Posted by Marshall Schor <ms...@schor.com>.
Here's a next iteration of set of ideas for logging support in V3.
1) Keep the v2 uima logging API - so users can migrate at their own speed (or
not...)
- but update the UIMA logger logj4 backend to switch it to log4j-2
2) Add SLF4j as a "facade" that supports log4j-2, logback and other back-end
loggers, configurable at deployment time.
- Has MDC and NDC (the stack version of MDC) support
https://logback.qos.ch/manual/mdc.html
- Has support for efficiency and Java 8 styles (e.g. using "Supplier<String>"
for messages)
- Has support for Markers
http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback
3) For Annotators, the base class they extend is augmented with getLogger() and
getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger with
the name of the Annotator implementation class. getLogger() is just shorthand
for the existing getContext().getLogger() api.
4) Extend the UIMA logger to externalize the hook to UIMA's resource bundle
message lookup (which uses the context's ResourceManger's extension class loader
if defined), so calls using the slf4j apis can use that if desired.
5) Update the existing documentation on how to configure backends to mention slf4j.
6) A plan to make use of the the slf4j logging in core UIMA. I'm new to this,
so please make suggestions for improvement!
a) Add to MDC: the Annotator being run (probably just the class name)
There are probably other things that should go into the MDC/NDC, but
I'm not sure what would be useful - suggestions welcome.
b) Use Markers to identify and control logging related to:
- annotator (flow-like tracing?)
- flow_controller
- feature structure (creation, updating) - trace-level
- index (operations like adding to / removing from) -trace-level
- index_copy_on_write - trace-level
- index_auto_rmv_add (when UIMA is automatically removing and adding
back FSs due to modification of key values) - trace-level
- serdes (serialization / deserialization)
Please consider this a first try; other suggestions welcome :-)
-Marshall