Ok, I see what you are doing.
Currently this is not supported. E.g. changing the relative ordering of the
Info and Error levels will confuse the way EventLogAppender maps to event
log entry types.

There are a couple of possible solutions:

One is to define (or redefine) the logging levels in the config file. This
would mean, for your situation, you would need to set the levels up in each
and every config file. This may also complicate the configuration of the
EventLogAppender (on the other hand it may make it more flexible). As levels
are immutable any code that needs to hold on to a level will have to listen
for repository configured events and re-lookup their level instances, this
might get quite complex.


The alternative would be to wait for the log4j implementation of domains
which may eclips levels altogether.

  "The next version of log4j will introduce the concept of domains
  allowing developers to log by multiple criteria, thus creating a much
  more powerful way of categorizing (i.e. classifying) logging
  statements, thus dispensing with the need to use various new levels
  (e.g. the trace level) to express logging/filtering criteria. With the
  introduction of domains the trace level will look like what it really
  is, a common but nonetheless a lame hack."

However I am not familiar with the details of the log4j domains proposal and
don't know if it would fulfil the re-ordering built-in classifications
requirement.


Right now I would have to say that configuring the levels via the config
file would be the most practical solution.


Cheers,

Nicko


 
> > What changes would you envision making? Especially what 
> would you be 
> > changing more than once?
> 
> Well, any changes I make to the Log4net code needs to be 
> updated when the next beta build comes along.
> 
> But anyways, in the way things work here, we'd really like to 
> see the INFO level being second lowest after ALL.  There are 
> some things we like to spit out to the log as information 
> only even when the log is set to only spit our ERROR levels.  
> Another example is having TRACE lower level than DEBUG.
> 
> > New levels can be created without modifying the log4net 
> code using the 
> > public Level constructor. Levels do not have to be declared in the 
> > Level class. Any level object can be passed to the 
> Ilogger.Log method. 
> > In order for a level name to be known when reading the 
> configuration 
> > file the level must be in the ILoggerRepository.LevelMap.
> 
> Well I really don't need to be creating new levels entirely, 
> as noted there is quite the collection of levels already defined.
> 
> 

Reply via email to