On a related note, is it time to promote log4j's DTD as the cross-language DTD (and rename it), since log4cxx and log4net, log4php, log4perl all support the DTD?
I would also like to discuss the most recent change to the DTD to add sequence number support to event as a required attribute. Is it the case that this sequence number will always be set and have a useful value? I'm not sure who will be setting the sequence number - if they're using a DB appender, the sequence number will exist, but only in the database, correct? Will this sequence number be 0 in other cases? is it the responsibility of the appender to set it? If it's zero everywhere except when retrieving the sequence number from the database, is it worth adding to the DTD? Chainsaw V2 relies on a similar mechanism, but uses a 'log4jid' property as the identifier. If the property doesn't exist when it's received, the property is added. Building a namespace of properties seems odd as well, but would be more flexible than modifying the DTD to support new features that were used by a subset of the events. If the user is logging to a database and a file, and the database is the source of the sequence number when it's sent to the database, would the file have a different sequence number? Scott -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Wed 4/28/2004 5:31 AM To: [EMAIL PROTECTED] Cc: Subject: Persisting LoggingEvents across languages Hi all, For log4j 1.3, I would like DBAppender, i.e. the successor to JDBCAppender, to be able to persist to a database in a format independent of the Java language. For most fields this is not a problem except for the MDC (a map), properties (a map) and exceptions (an array of type string). I am thinking of persisting each of these multi-valued fields into their own table. Thus, there will be a table for LoggingEvents containing most fields except for the throwable, MDC and properties. The MDC field will be stored in its own table, consisting of a foreign key to the owning LoggingEvent instance, a column for the key and a column for the value. Each row in the MDC table will correspond to one (value,key) pair in an MDC instance. The throwable would also be stored in its own table, with each row corresponding to a line in the stack trace. The properties map will be stored in the same way as the MDC. The advantage over java object serialization is that none of the fields would be opaque for the database and also programming language independent. Thus, one would be able to perform SQL queries on the MDC or the properties. (Give me all the events for userid=john). Do log4cxx, log4net, or log4pgp support persistence of logging events into a db? Should we work on this in a coordinated fashion? -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
<<winmail.dat>>
