logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: "Custom Container" logging
Date Tue, 21 Jun 2016 01:55:59 GMT
If you're still interested in this problem, you can use the EventLogger for
this sort of thing. Docs:

On 19 January 2015 at 06:50, David Lee <dlee@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
> dlee@calldei.com<mailto:dlee@calldei.com>
> http://www.xmlsh.org<http://www.xmlsh.org/>

Matt Sicker <boards@gmail.com>

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