logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: will there be a parameterized message in log4j like it is in slf4j?
Date Mon, 05 Oct 2009 01:32:12 GMT
OK. But let me phrase it a different way.

In order for a logging framework to support RFC 5424 - the new IETF  
Syslog specification - it must implement something to allow for  
structured data in a way that is compatible with that specification so  
that the Syslog appender can format the message correctly. In doing  
that it becomes easier to create standard appenders that can  
intelligently handle the structured data. The things you mention, such  
as database logging, become much easier with this "StructuredData"  
object then they would be with adhoc object structures.

Ralph

On Oct 4, 2009, at 5:11 PM, Jess Holle wrote:

> 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: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message