Let me start with a small disclaimer: I don't know anything about Ceki's (and possibly other log4j developers) concept of domains except what he wrote about it in this newsgroup.
However, I can imagine the following: Currently, we have one configurable dimension of categories for log entries (the logger name hierarchy) and one hard-coded dimension (the level 'hierarchy'). A much more flexible concept would be to allow the creation of loggers which are assigned to arbitrary many, configurable categories. Then everyone could introduce as many levels as necessary, just as it is possible now with logger names. > From: Endre Stĝlsvik [mailto:[EMAIL PROTECTED] [snip] > a) Performance impacts, as trace is an extremely verbose level. This approach should not impact performance at all. Maybe some more static variables are necessary. I would imagine the following usage. Instead of writing: public class Sample { private static Logger log = Logger.getLogger("my.log.hierarchy"); ... if (log.isTraceEnabled()) log.trace("User [id:"+user.getId()+"] added to update queue."); } You would write: public class Sample { private static Logger tracer = Logger.getLogger("my.log.hierarchy", "my.levels.trace"); private static Logger errlog = ...; ... if (tracer.isEnabled()) tracer.log("User [id:"+user.getId()+"] added to update queue."); } Maybe you like to introduce another dimension, e.g. the kind of access (read access vs. write access). That would allow you to ignore all read access log entries should any problems with data corruption occur: public class Sample { private static Logger writeTracer = Logger.getLogger("my.log.hierarchy", "my.levels.trace", "my.access.write"); private static Logger errlog = ...; ... if (writeTracer.isEnabled()) writeTracer.log("User [id:"+user.getId()+"] added to update queue."); } If you like the current logging style more, just write a small wrapper class: public class MyLogger { private Logger errLog; private Logger traceLog; ... public MyLogger(String name) { errlog = Logger.getLogger(name, "my.levels.error"); ... } public final isTraceEnabled() { return traceLog.isEnabled(); } public final trace(String s) { traceLog.log(s); } } I didn't do any performance measurements, but I'm pretty sure that the additional call of a final method is negligible (probably zero if the compiler does decent optimization). Btw., you could do something similar even with the current version to hide a self-defined Level subclass. > b) Levels define an implicit view of the -importance- of a > log-statement - > and not "where it comes from", or who should view it, as such. It's a > descriptive -importance level-. Domains wont supersede this. This depends on how abstract domains are designed. From a conceptual viewpoint, you have several dimensions of categories (logger names, levels, etc.) which don't need to be implemented by different means. Based on this abstraction everyone can choose (or create) his personal logging dimensions, of which 'where it comes from' and 'importance level' are just two examples. > c) Trace is something else! In the view described above it's just one more category in one dimension. As I said, I have no idea if this is what Ceki has in mind, these are just conjectures. --Wolf ps: I must admit that I find it a bit strange that publication of the design and source code for a new concept is delayed for the sake of increasing the attraction of a conference. But maybe this is a too idealistic view of open source development. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
