Logger / level design is my million dollar question. My application will have an adminstration console where logging levels, appenders, and layout can be specified. I'm hiding the details of log4j and presenting them some simple choices. Log to a console or file. Select browser format (i.e. html) or xml format. Email notification, etc. They can also turn logging on or off, or specify INFO or ERROR.
Some sites may only want to track user login and logout sessions. So, I thought of adding a level named SESSION to facilitate this choice. I also need to persist the choices made so when the application is restarted the logging choices are re-established. I am trying to do this without an additional config file - this may be a problem. I plan to modify and write out the log4j config file whenever a change occurs - hoping I can codify the changes strictly within the confines of the log4j config file syntax. My thinking is the SESSION level helps me do this as this specific level doesn't exist. As all good frameworks, log4j gives lots of options and flexibility. I'm thinking of a logger hierarchy where the appender is the - potentially - least used as you go up the hierarchy. Something like File -> Console - > Email. I hope this makes sense. -S On Aug 2, 2005, at 3:33 PM, Steve Pruitt wrote: > All, > > I am adding a custom level for my application. The level name is > SESSION and it has a severity level between INFO and WARN. > Documentation says each level must have a unique integer value. > I'm not > sure how to define the value for my level. Looks like it could either > be INFO + 1 or WARN - 1. But, I am a little confused. If the > existing levels are in simple order, doesn't INFO + 1 = WARN and > wouldn't it violate the uniqueness rule. Or, is there some > progression used to separate the builtin level values to make room for > custom levels. Or, do I completely misunderstand how the builtin > levels are implemented? > Are you very sure that you want to do this as a Level? From the name it seems like your "Level" is more likely a class of information (or less likely the intended audience) instead of the significance of the message. Would definitely be simpler to use distinct loggers or distinct logger hierarchy for the "session" information instead of trying to add a new level. I think level is wrong way to go, but I'd still like to make it possible to introduce new levels without having to add code. Almost all the internal stuff is based on the integer value, the most significant role for the Level class is to implement the conversion between integer values and a labels. It would be nice have some generic code so that if you wanted, you could have 9999 levels between INFO and WARN, but by default they'd be rendered as INFO+1000 or the like. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
