In my case, I prefer to allow the data to be structured in a means that
makes sense to my application (JMX AttributeList's and provider
classes/interfaces thereof thereof make great sense in my case). A
particular appender can then translate this into whatever makes sense
for another system. In the case of database logging it can use
structured data field names and knowledge of the target database table
to fill in the table with configuration required only in the exceptional
case. This is far more useful than simply stuffing the entire message
into a database column.
Ralph Goers wrote:
If you want to pass "structured data" I suggest you look at RFC
5424.(See http://tools.ietf.org/html/rfc5424) Although the RFC is for
syslog I have proposed (and implemented) support for this in SLF4J and
in Logback. I am just waiting for Ceki to review and accept it.
Ralph
On Oct 4, 2009, at 11:53 AM, Jess Holle wrote:
Code using using org.apache.log4j.Logger would continue to work as
is, ensuring backward compatibility, at least as far as the log4j
signatures are concerned. Users who rely on the fact that the
message argument was an Object instead of String would need to
modify few lines of code. In the worst case, this change could cause
loss of logging information but would NOT cause compile-time
problems or issues related to method signatures.
This is a key ability in log4j, which I for one leverage to pass
complex, structured data to specialized loggers, e.g. to dissect
these structures and place various fields into separate relational
database columns.
Losing first class access to such abilities is a non-starter.
--
Jess Holle
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
