[logback-dev] MessageFormatter

[Joern Huxhorn]

On 20.01.2010, at 14:36, Rü wrote:

>
> Hi Joern,
>
>
> Joern Huxhorn-2 wrote:
>>
>> I'd be happy if you could take a few minutes and check out my  
>> proposal.
>>
>
> You where kidding, right?!? "a few minutes"... well, I still did  
> take a
> look. Nice proposal and it's good to know that there might be some  
> things
> like that coming. Passing your own Message instances into the API  
> would be
> powerful and definetely a gain. But I think that's not only an API  
> change,
> it's a completely different design. I'd say: That's a too big a step  
> for
> SLF4J to reasonably take. Why not put it into a separate structured  
> logging
> artifact that wrapps SLF4J.

The original SLF4J API would stay untouched for compatibility reasons.  
Sorry about the "few minutes" ;)
It's possible to provide the new API by wrapping the old one (I've  
prepared exactly that already) but implementing it "natively" would  
enable Appenders (in case of Logback) to work on Messages instead of  
Strings, opening up lots of new opportunities.

> The impact on performance the wrapping will have
> is probably in the same range a that you'd introduce by replacing e.g.
> debug(msg, arg0) with debug(msg, new Object[] { arg0 }) by only using
> varargs... hotspot is really smart, you know?
>
> For the varargs discussion, I like Cekis suggestion
> http://bugzilla.slf4j.org/show_bug.cgi?id=31#c31 31-31  best.
>

That comment refers to a previous proposal that merely changed the  
Object[] into Object...
I've instead added a new, additional API that you can either use  
instead of the old one or ignore. This has the advantage that projects  
requiring JDK1.4 could still be supported.

>
>
>> Changing the default message format (or making it configurable) of
>> Logback, on the other hand, isn't a good idea since the contract of  
>> it
>> is derived from SLF4J. Any SLF4J implementation must be able to
>> support the new formatting.
>>
>
> Your warning is legitimate! But I don't want to change the message  
> format, I
> want to change the formatter! I don't want to e.g. put extra stuff  
> within
> the curly bracket placeholders, generally preventing other SLF4J
> implementations from working properly. But I do want to change what  
> goes in
> there. I.e. when I want to log a message with an argument that's an  
> instance
> of a class that doesn't override toString to my liking (most  
> notably: not at
> all), I want to provide my own formatter for all instances of that  
> class.
> Anything else would be my own risk... if I'd ever choose to go away  
> from
> logback, that is ;)
>

I think the main problem is that adding such an ability will have an  
impact on the standard formatter performance. Additional lookup is  
needed to check if a special formatter is registered - for every  
parameter.
I don't say that this will be terribly expensive but a certain cost  
will be created.

> Put simply, your proposal requires the caller code to change (as  
> well as
> SLF4J, Logback, and many others) while my change would work with  
> logging
> calls from third party libraries as well ;-)
>

That's not really the case.
You can either leave everything as it is right now, since SLF4J API  
would stay binary-compatible, or switch to the new API by simply  
changing the import of Logger and LoggerFactory. This can easily be  
done by a quick search & destroy/replace.

The same is the case for third-party libraries/implementations of  
SLF4J other than Logback. They will still work as before, even if the  
new API is used, since the original SLF4J would simply be wrapped.

In case of a more modern implementation that natively implements the  
new SLF4J API, the old API would be implemented by wrapping the new API.

Thoroughly confused? ;)

Regards,
Jörn.

> Regards
> Rü
> -- 
> View this message in context: http://old.nabble.com/MessageFormatter-tp27209919p27241839.html
> Sent from the Logback Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev