If you want to perform ad-hoc querying of events, I'd suggest you define the conventions (MDC keys, logger names and/or message content) and then use Chainsaw's querying/filtering/search capabilities.
Chainsaw is available via Web Start at http://logging.apache.org/log4j/docs/chainsaw.html Chainsaw can tail log files, read events out of the database or accept events over a socket. You can find the list of supported receivers from Chainsaw's help menu - each receiver's JavaDoc describes the required configuration parameters. Scott -----Original Message----- From: Daniel Einspanjer [mailto:[EMAIL PROTECTED] Sent: Wed 1/19/2005 1:00 PM To: [EMAIL PROTECTED]; [email protected] Cc: Subject: Advice requested on best way to implement log4* to support non-hierarchal categories My company is looking to standardize our logging across all of our C++ (and eventually Java) projects and we would certainly rather use a well-known architecture such as log4j/log4cxx rather than growing our own. My biggest challenge is that one of the key desires our developers have is to be able to mix and match the selectiveness of the logging. The easiest way to explain would probably be by example. We would like to be able to easily mix and match any of the following categories of log messages: * performance/timing related * search result related * search result quality related * any messages in the hierarchy com.foo * no messages from the class/hierarchy com.foo.bar We were hoping to be able to define the characteristics of log messages within the class com.foo.bar so that we could have overall performance log messages, search result performance messages, search result quality messages, overall search result messages, etc. and then via configuration we could say, "hrm, lets take a look at the search result quality across all of com.foo. Is anyone else doing anything like this out there? I have done quite a bit of reading on the log4j and log4cxx documentation, but I have not found a good resource for explaining the Filter class hierarchy. Any pointers or advice is welcome. Thanks, Daniel E. --------------------------------------------------------------------- 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]
