Chad, > If I recall correctly, it was impossible to create new > appenders and add them to the root or maybe remove them, > something like that. Since appenders are loaded only when a > logger is first created and references it, there was no way > to add one after-the-fact. I may be slightly wrong, but it > was something around there.
It is true that there isn't an easy way to get the appenders that are defined. The only way to do this is to search through each logger for its appenders. It is possible to add and remove appenders, but only from the logger to which they are attached, not generally from the whole system. It would be possible to have a central list of all the defined appenders. That would mean making a change to the appender naming convention to indicate that the appender name must be globally unique. Currently the appender name is only unique within the configuration file. I will look into the cost of adding this feature. > Also, managing loggers wasn't straight forward; the API is > designed primarily for extensibility, not runtime management, > so that made it difficult, obviously, to manage it. The APIs are not strongly typed because they are designed for flexibility. This means that there ends up being a lot of casting which leads to messy code. Also there is no way to discover the configuration options for a component. This means that it is only possible to write configuration handling for specific (and known) appenders, layouts, filters, evaluators etc... It would be possible to use a framework similar to the Visual Studio component designer to allows some introspection of configurable components. > The reason I ultimately dropped it is it would take a semi- > to fully-major effort to redesign the interfaces to > facilitate runtime configuration. The API is designed around > being configured from within rather than from without. To > change it would require it to be designed to be configured > from without and the various XXXConfigurators would merely > operate on the APIs like anyone doing it manually would do. The reason that the configurators do not use a standard API to configure the LoggerRepository is simply to allow different implementations of the ILoggerRepository interface to work differently. Currently we only have the Hierarchy implementation. At some point in the future we may have to take a view on whether we feel there will ever be a need to have a different implementation of ILoggerRepository. Nicko > Anyhow, it's probably something to think about for v2 or > perhaps a .5 release. It's not going to change anytime soon > unless a bunch of people have a lot of free time. > > -Chad > > -----Original Message----- > From: Nicko Cadell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 26, 2004 11:55 AM > To: 'Log4NET User' > Subject: RE: Question on SDK Classes > > > > The most frustrating part of this is that log4net ALMOST has > > the ability to be programmatically configured. It's about 75% > > the way there, but there are a few key things you cannot do > > programmatically and so you have to give up and do the > > file-mangling hack. > > > > </rant> > > > > -Chad > > I hear you. What can't you do programmatically? What are the specific > use > cases? > If there is anything that we can do in the short term without breaking > the > current model then we should look at doing it. We also should plan to > improve this area in future. > > Nicko > >
