logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lee <d...@calldei.com>
Subject "Custom Container" logging
Date Mon, 19 Jan 2015 12:50:38 GMT
I have an normally command line or embedded application that can start a separate instance
of itself
in a GUI (could be non GUI ...) this instance is in a new thread and  thread group.

I would like to be able to capture the log events generated by this new instance in some way
independent of the other instances or the main app.
The main purpose is to show a 'event logging' debug window.

In log4j(1) I was able to add a new appended at runtime, and I was somewhat but not quite
as successful
in log4j2.   I came to the conclusion that trying to mimic log4j1 runtime appenders is not
the best way to do this.
( as is documented,  updating the configuration is the recommendation).

Before proceeding on that route I'd like to consider alternatives.   For example the ContextSelector
looks like
the right integration point.
I am a bit unclear on how this works.   Currently I use exclusives static variable defined
loggers, e.g.
         Logger mLogger = LogManager.getLogger();
But while I make heavy use of custom class loaders and the default is documented as ClassLoaderContextSelector(),
they all seem to end up in the same context (which is generally good) ...  - but the docs
don't describe how that works,
"This ContextSelector chooses a LoggerContext based upon the ClassLoader of the caller."

One read of this implies each class loader would get its own logger context, but I'm not seeing
that - or maybe Im not looking
hard enough ( log events from all loggers seem to correctly go through the same context, configuration
and spenders).

The BasicContextSelector looks promising:
  "Returns either this Thread's context or the default LoggerContext."

But I don't see where it is that I would set this context instance.  I do manage the thread
local storage, associate the correct class loader
into the thread local and also assign each independent set instances into their own thread
But I understand how I would arrange for a particular context select to make use of this or
where I would configure it

Another alternative I tested does seem to work, which is to create a top level generic appended
that always gets every event.
Right now it does  nothing but I can arrange for it to at runtime examine the thread local
and route messages accordingly.

Suggestions on what approaches to consider that are intended for this type of use are appreciated.

David A. Lee

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