Mark,
In a nutshell, I want to configure two different appenders, let's say a
DB appender and a file appender. One of them would be active by
default, but the user could switch to the other, referring to it by name
as specified in the props, without having to create a new
appender from scratch.
Now looking more closely, appenders seem not to be named resources (as
the properties format suggests), but rather one-shot instances.
In fact attaching an existing appender to another Logger
programmatically would be a mistake since detaching that appender from
either
Logger would close it.
A more solid architecture would separate the concerns of appender
specification (e.g. through XML or properties), appender instances and
appender resources. What I would be most interested in are named
appender specifications, whether instantiated or not, which I could then
instantiate dynamically and which would share the resource (data sink)
specified with any other existing instances of the specification.
One nice aspect of this thinking is that the properties format seems
already to support this notion even if the implementation falls short of
it.
Martin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: July 6, 2002 11:36 PM
To: Log4J Developers List
Subject: RE: Access to all configured, possibly dangling, appenders
Martin,
> Unfortunately there doesn't seem to be a provision for programmatic
> access to _all_ Appenders, e.g. those configured in a
> PropertyConfigurator. In fact PropertyConfigurator _clears_ the list
> of appenders and is proud of it.
What other appenders would there be? If an appender is not attached to
a logger, then it is not used, is not referenced, so it should get
released.
> Is there a PropertyConfigurator variant out there which
> A) creates _all_ the appenders in the properties file (not just those
> which happen to be used),
> B) gives the application programmatic access to the list of _all_
> existing Appenders, whether in use or not.
> C) allows to remove a specified appender
> D) allows to remove all unused appenders
Again, appenders are only referenced in relation to the logger(s) they
are attached to. There is no other mechanism for storing appender
objects (like an AppenderRegistry). You can always write your own
configurator that does this for you, but it will be a tough row to hoe.
For one thing, all the appenders for a given logger are cleared when a
logger is configured via the configuration file. This will affect any
other logger (or your registry) that also has a reference to the same
appender.
What problem are you trying to solve?
-Mark
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.361 / Virus Database: 199 - Release Date: 07/05/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.361 / Virus Database: 199 - Release Date: 07/05/2002
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
