In general, I agree with Joern. The point of the Message interface is to make
it easy to create all different kinds of Messages. A StructuredData message
really has no good way to implement addParam() or event addThrowable.
Ralph
On Apr 26, 2010, at 5:09 AM, Joern Huxhorn wrote:
>
> On 26.04.2010, at 10:58, Ceki Gülcü wrote:
>
>> On 24/04/2010 3:55 PM, Joern Huxhorn wrote:
>>
>>> One of my goals in slf4j-n was to reduce the number of methods in the
>>> Logger interface.
>>> This was seemingly a bad idea since it would have a performance impact,
>>> in the case where a message isn't actually logged, as Ralph reported.
>>>
>>> Because of this, it would be very wise to keep all the methods that are
>>> already present in the Logger interface and simply add
>>> debug(Message)
>>> debug(Message, Throwable)
>>> debug(Marker, Message)
>>> debug(Marker, Message, Throwable)
>>> [same for other levels plus generic log(Level, ...)-methods]
>>>
>>> The designer in me doesn't like the "bloated" (in the sense that some
>>> methods could be dropped without losing functionality) interface, but
>>> the realist in me accepts that performance is more important than
>>> aesthetics ;)
>>
>> Can't we coalesce debug(Message), debug(Message, Throwable), debug(Marker,
>> Message) and debug(Marker, Message, Throwable) into a single variant?
>>
>> Here is an idea:
>>
>> try {
>> ...
>> } catch(Throwable t) {
>> Message m = new Message("hello{}").addParam("word").add(marker).add(t);
>> logger.error(m);
>> }
>>
>> This approach incurs the cost of creating and building the Message object
>> regardless of whether the request will be logged or not. I suspect that the
>> bulk of the cost is due to the object creation incurred by new Message(...)
>> and not due to the addition of extra data incurred in calling addParam() and
>> the other add() methods. Thus, performance-wise we are in the same position
>> as the original Message proposal but now we can get rid of all the
>> overloaded variants dealing with Marker and throwable.
>>
>
> Well, the idea of the Message interface (!) was to enable lazy initialization
> (in contrast to a simply toString) without adding too many additional
> requirements to it.
>
> http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/org/slf4j/core/Message.java
>
> It would be much more work to implement a custom Message with the suggestion
> above. More work implies more chances of faulty implementation, for example
> in case of Marker support. The addParam() method would be quite a mistake,
> too, since a different implementation of Message might use key/value-pairs as
> parameters. (This is something that I'd really like to do since it would also
> enable easier translations)
>
> I see that interface as the main extension point of SLF4J & Logback. The
> Message instance is supposed to end up in the appenders in case of Logback,
> so custom appenders could handle custom Message implementations in arbitrary
> ways without having to parse anything.
>
> We could, however, add the Throwable to the Message interface. I left it out
> of the interface and added it only to the ParameterizedMessage implementation
> to keep the interface as clean as possible.
>
> This would reduce the interface to debug(Message) and debug(Marker, Message),
> at least.
>
> How about
>
> interface Message
> {
> Message set(Throwable); // instead of setThrowable to be more concise?
> Throwable getThrowable();
> }
>
> in addition?
>
> My problem is: I'm not really sure if I'll like this while using it ;)
> Regardless of the way we'll implement it in the Message, it will always be
> less concise (concerning both brevity and readability) than code using the
> four methods...
>
> Joern.
> _______________________________________________
> slf4j-dev mailing list
> [email protected]
> http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
