If you're still interested in this problem, you can use the EventLogger for this sort of thing. Docs: https://logging.apache.org/log4j/2.x/manual/eventlogging.html
On 19 January 2015 at 06:50, David Lee <d...@calldei.com> wrote: > 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 > d...@calldei.com<mailto:d...@calldei.com> > http://www.xmlsh.org<http://www.xmlsh.org/> > > -- Matt Sicker <boa...@gmail.com>
