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 that's
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 group.
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
[email protected]<mailto:[email protected]>
http://www.xmlsh.org<http://www.xmlsh.org/>
