uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joern Kottmann <kottm...@gmail.com>
Subject Re: uima v3 logging
Date Sat, 11 Feb 2017 23:52:17 GMT
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 <msa@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 <msa@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
> >>>>
> >>>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message