On Feb 20, 2010, at 8:27 AM, Jess Holle wrote:
> On 2/19/2010 10:22 PM, Curt Arnold wrote:
>> On Feb 19, 2010, at 5:42 PM, Christian Grobmeier wrote:
>>
>>> However - we (all who are interested in continuing log4j) need to
>>> discuss other options. Using SLF4J as native interface or not might be
>>> the next discussion. Looking at the current code we currently have is
>>> the next one.
>>>
>> Before jumping into implementation issues, I think it would be best to try
>> to collect as many potential requirements, design principles, etc, so we
>> know what things are important to us and to our potential users before
>> starting to make design decisions. There are several usable logging
>> frameworks out there, it would be good to know what issues are bothersome,
>> limiting, irritating, desirable, etc. We may need to sacrifice one feature
>> for another, but it would be best to know that we are making trade-offs.
>>
>> I requested a log4j 2.0 JIRA (https://issues.apache.org/jira/browse/LOG4J2)
>> several years ago to serve as a place to collect that type of info. I've
>> entered much of the stuff there, but none of them should be taken as
>> mandates or directives. They are ideas. I thought they were good at the
>> time. I would love to see other people throw in their ideas and pains, help
>> refine others, etc. At some point, we can start to narrow down which are
>> required, desirable, marginal or impractical.
>>
>> Probably would be good to invite the other ASF projects that have a logging
>> dependency to post their issues, concerns or wishes.
>>
>> Supporting SLF4J as an interface is already logged as a design issue
>> (http://issues.apache.org/jira/browse/LOG4J2-27). However, I think it is
>> strongly desirable to make much of log4j 2.0's back-end classes independent
>> of the logging API which was the gist of LOG4J2-5.
>>
>> In my mind, what defines log4j 2.0 are LOG4J2-3 (fine grained locking) and
>> LOG4J2-7 (designed for JDK 5+) with LOG4J2-4 being likely the next most
>> significant.
>>
>> Experimenting with some of the core issues to clarify ideas is probably
>> valuable. The stuff I did in the sandbox was to explore LOG4J2-13 (distinct
>> extract/render phases) and LOG4J2-5 (backend independence from API).
>>
>> Another area worthy of exploration is LOG4J2-9, basically designing log4j
>> 2.0 to be configurable from multiple configuration frameworks.
>>
> Those sound like good targets.
>
> One thing I'd like to make sure is not lost is an easy way to pass an Object
> rather than a String.
I'd prefer a Message instead of an Object. The primary difference is that the
Message is an interface that looks like:
/**
* An interface for various Message implementations that can be logged.
*/
public interface Message extends Serializable {
/**
* Returns the Message formatted as a String.
* @return The message String.
*/
String getFormattedMessage();
/**
* Returns the format portion of the Message
* @return
*/
String getMessageFormat();
/**
* Returns parameter values, if any.
* @return An array of parameter values or null.
*/
Object[] getParameters();
}
For SLF4J I implemented a ParameterizedMessage (message and parameters), a
SimpleMessage (message string only), and StructuredDataMessage (to support RFC
5424), but all kinds of Message objects could be created. This makes it easy
for appenders and layouts because they just need to call getFormattedMessage()
to include that in the layout, or they can get to the "message" via
getMessageFormat() or the "parameters" via getParameters().
Ralph
>
> This allows custom appenders and layouts to recognize particular Object types
> and do things like route fields, map values, or the like to separate database
> or CSV/TSV columns -- while letting the Object provide a toString() or using
> a custom renderer for other cases.
>
> If only a String is passed or using clumsy syntax is required to pass an
> Object, then such richly structured output is defeated.
>
> --
> 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]
